1. UNIT II

2. Contents Functional and non-functional req.
Requirement engineering process
Requirement elicitation techniques
Software requirement specification(SRS)

3. Requirements Engineering
Requirement: A function, constraint or other property that the system must provide to fill the needs of the system’s intended user(s)
Engineering: implies that systematic and repeatable techniques should be used
Requirement Engineering means that requirements for a product are defined, managed and tested systematically

4. Purpose of requirement
The purpose of Requirements is:
To come to an agreement with the customer and the users on what the system should do.
To give system developers a better understanding of the requirements of the system.
To delimit the system.
To provide a basis for planning the technical contents of the iterations.
To define a user interface of the system.

5. Functional requirements
These are the statement of services the system should provide
How the system should react to particular i/p and
How the system should behave in particular situations
In some cases, it may also explicitly state what the system should not do

6. A functional requirement for a milk carton would be “ability to contain fluid without leaking”

7. Functional requirements for the MHC-PMS
Chapter 4 Requirements engineering
Functional requirements for the MHC-PMS
A user shall be able to search the appointments lists for all clinics.
The system shall generate each day, for each clinic, a list of patients who are expected to attend appointments that day.
Each staff member using the system shall be uniquely identified by his or her 8-digit employee number.

8. Non functional requirements
Constraints on the services or functions offered by the system such as timing constraints, constraints on the development process, standards, etc.
Often apply to the system as a whole rather than individual features or services.
Non-functional requirements cover all the remaining requirements which are not covered by the functional requirements.

10. Non-functional requirements
These define system properties and constraints e.g. reliability, response time and storage requirements. Constraints are I/O device capability, system representations, etc.
Process requirements may also be specified mandating a particular IDE, programming language or development method.
Non-functional requirements may be more critical than functional requirements. If these are not met, the system may be useless.

12. Some typical non-functional requirements are:
Performance – for example Response Time, Throughput, Utilization
Scalability
Capacity
Availability
Reliability
Recoverability
Maintainability
Serviceability
Security
Regulatory
Manageability
Environmental
Data Integrity
Usability
Interoperability

13. Req. engg process
The goals of the req engg process is to create and maintain a system req document.
Overall process included 4 high level req engg sub processes along with one additional activity of req management.
Feasibility study
Req. elicitation and analysis
Req. specification
Req. verification and validation
Req management

15. Verification: Are we building the product right?
Validation: Are we building the right product?

16. Feasibility study Req engg process should start with feasibility study
The result of study is report that recommends whether or not
Its worth carrying no with the req engg and system development process
Feasibility study includes
Technical feasibility
Operational
Economic
Management
Legasl
Time
social

17. 2. Req elicitation(activities) and analysis
It includes following activities
interacting with stakeholders in the system to collect their req’s.
Takes the unstructured collecting of req, group related req and organizes
Priotising req and finding and resolving req conflicts though negotiation

18. 3. Req specification
It is the process of writing down the user & system req into a req document
Req should be clear, unambiguous, easy to understand, complete and consistent

19. 4. Req validation
Is the process of checking; the req actually define the system that the customer really want.
Req validation is important because error in req document can leads to extensive rework and cost
When these problems are discovered during development or after the system is in service.
During req validation, different type of checks should be carried out in the req document:
Validity checks
Consistency checks
Completeness checks
Realism checks
Verifiability

20. 5. Req manmangement

21. Requirement elicitation techniques
Interviews
Brainstorming
Task analysis
Form analysis
User scenario and use case based req. elicitation
Delphi
Domain analysis
Joint application design (IBM in 1970)
Facilitated application specification techniques(FAST) (JAD, brainstorming)
prototyping

22. Software requirement specification(SRS)
SRS contains the complete descriptions of s/w without much about implementation details
It’s a set of precisely stated properties and constraint on which the final product must satisfy

23. SRS must address the following issues.
FR in terms of i/p required, o/p generated and the processing details.
N-FR , e.g. accuracy, efficiency, maintainability etc
Execution constraints, e.g. response time, throughput
Standards to be followed
Security requirements
Interface with other external agents; person, s/w or h/w

24. Characteristics of a SRS document
Correctness
Completeness
Consistency
Unambiguousness
Stability
Modifiability
Verifiability
Traceability
Testability
Understandable by customer
Right level of abstraction

25. Users of a requirements document