UNIT II

Software Requirements
Table of contents
Functional and non-functional – User- System-
Requirement Engineering Process- Feasibility
Studies- Elicitation- Validation and
Management- Software Prototyping-
Prototyping in the software Process- Rapid
prototyping techniques- User Interface
prototyping –S/W document-Analysis and
modeling-data, functional and behavioral
models-Structural analysis and data dictionary
 Definition:

Requirement Engineering
The requirements for a system are the descriptions of
● what the system should do
● the services that it provides
● the constraints on its operation
These requirements reflect the needs of customers for a system that serves a certain purpose
such as controlling a device, placing an order, or finding information. The process of finding
out, analyzing, documenting and checking these services and constraints is called requirements
engineering (RE).
● If a company wishes to let a contract for a large software development project, it
must define its needs in a sufficiently abstract way that a solution is not predefined.
● The requirements must be written so that several contractors can bid for the contract,
offering, perhaps, different ways of meeting the client organization’s needs.
● Once a contract has been awarded, the contractor must write a system definition for
the client in more detail so that the client understands and can validate what the
software will do.
● Both of these documents may be called the requirements document for the system.
‘User requirements’ to mean the high-level abstract requirements
User requirements are statements, in a natural language plus diagrams, of what
services the system is expected to provide to system users and the constraints
under which it must operate.

‘System requirements’ to mean the detailed description of what the system should do

System requirements are more detailed descriptions of the software system’s

functions, services, and operational constraints. The system requirements document

(sometimes called a functional specification) should define exactly what is

to be implemented. It may be part of the contract between the system buyer and

the software developers.

Ex:User and system requirements
Readers of different types of requirements
specification
Functional and
Non-functional
reuirements
● Software system requirements are often classified as functional requirements
or nonfunctional requirements

● Functional requirements
These are statements of services the system should provide, how the system
should react to particular inputs, and how the system should behave in
particular situations.
In some cases, the functional requirements may also explicitly state what the
system should not do.
● Non-functional requirements
These are constraints on the services or functions offered by the system.
They include timing constraints, constraints on the development process, and
constraints imposed by standards.
Non-functional requirements often apply to the system as a whole, rather than
individual system features or services
(In reality, the distinction between different types of requirement is not as clear-cut as
these simple definitions suggest)
Functional requirements
● The functional requirements for a system describe what the system should do.
● Depend on the type of software being developed, the expected users of
the software, and the general approach taken by the organization when writing requirements.
● When expressed as user requirements, functional requirements are usually described in an
abstract way that can be understood by system users.
● Functional system requirements describe the system functions, its inputs and outputs,
exceptions, etc., in detail.

Examples of functional requirements for the MHC-PMS system:

1. A user shall be able to search the appointments lists for all clinics.
2. The system shall generate each day, for each clinic, a list of patients who are
expected to attend appointments that day.
3. Each staff member using the system shall be uniquely identified by his or her
eight-digit employee number.
Non-functional requirements
Not directly concerned with the specific services delivered by the system to its users.

Relate to emergent system properties such as reliability, response time, store occupancy,
performance, security, or availability.

Alternatively, they may define constraints on the system implementation such as the capabilities of
I/O devices or the data representations used in interfaces with other systems.

Although it is often possible to identify which system components implement specific functional
requirements (e.g., there may be formatting components that implement reporting requirements), it is
often more difficult to relate components to non-functional requirements
The implementation of these requirements may be diffused throughout the system. There are two
reasons for this:
1. Non-functional requirements may affect the overall architecture of a system rather than the
individual components. For example, to ensure that performance requirements are met, you may
have to organize the system to minimize communications between components.

2. A single non-functional requirement, such as a security requirement, may generate a number of

related functional requirements that define new system services that are required. In addition, it
may also generate requirements that restrict existing requirements.
Requirements engineering processes
Links
● Requirement Engineering process :
https://slideplayer.com/slide/8714092/

● User Interface Prototype

https://www.slideshare.net/memmel/user-interface-prototyping

Data Model
● https://www.slideshare.net/RAAVIthrinath/data-modeling-28330266

● https://www.youtube.com/watch?v=FXRskT6bXyA

● https://www.youtube.com/watch?v=cYoqLRIYCIE&list=PLRt-r4QiDOMexY3KGGQ2YSC_tMeJy5XGV&index=2
Software Prototyping
● Prototype methodology is defined as a Software Development model in which a
prototype is built, test, and then reworked when needed until an acceptable
prototype is achieved. It also creates a base to produce the final system.
● Software prototyping model works best in scenarios where the project's
requirement are not known. It is an iterative, trial, and error method which take
place between the developer and the client.
Prototyping Model has following six SDLC phases as follow:
Step 1: Requirements gathering and analysis
● A prototyping model starts with requirement analysis. In this phase, the requirements of the system are defined
in detail. During the process, the users of the system are interviewed to know what is their expectation from
the system.
Step 2: Quick design
● The second phase is a preliminary design or a quick design. In this stage, a simple design of the system is
created. However, it is not a complete design. It gives a brief idea of the system to the user. The quick design
helps in developing the prototype.
Step 3: Build a Prototype
● In this phase, an actual prototype is designed based on the information gathered from quick design. It is a
small working model of the required system.
Step 4: Initial user evaluation
● In this stage, the proposed system is presented to the client for an initial evaluation. It helps to find out the
strength and weakness of the working model. Comment and suggestion are collected from the customer and
provided to the developer.
Step 5: Refining prototype
● If the user is not happy with the current prototype, you need to refine the prototype according to the user's feedback and
suggestions. This phase will not over until all the requirements specified by the user are met. Once the user is satisfied
with the developed prototype, a final system is developed based on the approved final prototype.
Step 6: Implement Product and Maintain
● Once the final system is developed based on the final prototype, it is thoroughly tested and deployed to production.
The system undergoes routine maintenance for minimizing downtime and prevent large-scale failures.
Types of Prototyping Models
Four types of Prototyping models are:
● 1. Rapid Throwaway prototypes
● 2. Evolutionary prototype
● 3. Incremental prototype
● 4. Extreme prototype
Rapid Throwaway Prototype
● Rapid throwaway is based on the preliminary requirement. It is quickly developed to show how the
requirement will look visually. The customer's feedback helps drives changes to the requirement, and
the prototype is again created until the requirement is baselined. In this method, a developed prototype
will be discarded and will not be a part of the ultimately accepted prototype. This technique is useful
for exploring ideas and getting instant feedback for customer requirements.
Evolutionary Prototyping
● Here, the prototype developed is incrementally refined based on customer's feedback until it is finally
accepted. It helps you to save time as well as effort. That's because developing a prototype from
scratch for every interaction of the process can sometimes be very frustrating. This model is helpful
for a project which uses a new technology that is not well understood. It is also used for a complex
project where every functionality must be checked once. It is helpful when the requirement is not
stable or not understood clearly at the initial stage
Incremental Prototyping
● In incremental Prototyping, the final product is decimated into different small prototypes and developed individually.
Eventually, the different prototypes are merged into a single product. This method is helpful to reduce the feedback
time between the user and the application development team.

Extreme Prototyping:
Extreme prototyping method is mostly used for web development. It is consists of three sequential phases.
● 1. Basic prototype with all the existing page is present in the HTML format.
● 2. You can simulate data process using a prototype services layer.
● 3. The services are implemented and integrated into the final prototype.
User Interface Prototype
● https://www.slideshare.net/memmel/user-interface-prototyping
Data Model
● https://www.slideshare.net/RAAVIthrinath/data-modeling-28330266
UML Overview
● https://www.youtube.com/watch?v=FXRskT6bXyA

● https://www.youtube.com/watch?v=cYoqLRIYCIE&list=PLRt-r4QiDOMexY3KGGQ2YSC_tMeJy5XGV&index=2
Resources

● Ian Sommerville.(2012).Software Engineering.Ninth Edition.Pearson

Education Asia.