1. Requirements Engineering
Chapter 4:
Requirements Engineering
Chapter 4 in Software Engineering Book.

2. Overview What are software requirements? Functional requirements.
Non functional requirements.
User and System requirements.
Why is it important to get it right?
The SRS document.
Requirements Engineering process.

3. By the end of this chapter, you will..
Understand the concept of software requirements.
Understand the difference between functional and non functional requirements.
Understand the importance of getting it right.
Understand how requirements are documented.
The SRS document.

4. What are software requirements?
“The descriptions of the system services and constraints that are generated during the requirements engineering process.”
Developed during the first phase in the software development life cycle.

5. Requirements Types Functional requirements.
Non-functional requirements.
Domain requirements.

6. 1. Functional Requirements
What requirements (What the product must do).
Describe functionality or system services (what are the inputs, the outputs and expectations).
Depend on the type of software, expected users and the type of organization where the system is developed.

7. 1. Functional Requirements
Functional requirements can be:
User requirements are high-level statements of what the system should do.
System requirements should describe the system services in detail.

8. The LIBSYS Case Study
A library system that provides a single interface to a number of databases of articles in different libraries.
Users can search for, download and print these articles for personal study.

9. The user shall be able to search either all of the initial set of databases or select a subset from it.
Example 1:

10. Every order shall be allocated a unique identifier (ORDER_ID) which the user shall be able to copy to the account’s permanent storage area.
Example 2:

11. User & System Requirements
User Requirements
System Requirements
Written for customers.
Statements in natural language.
Describe the services the system provides and its operational constraints.
May include diagrams or tables.
Should describe functional and non-functional requirements.
Should be understandable by system users who don’t have detailed technical knowledge.
Statements that set out detailed descriptions of the system’s functions, services and operational constraints.
Defines what should be implemented so may be part of a contract between client and contractor.
Intended to be a basis for designing the system.
Can be illustrated using system models.
We provide a definition for a user requirement.
We provide a specification for a system requirement.

12. Definition & Specification
User requirement definition:
LIBSYS shall keep track of all data required by copyright licensing agencies in the UK and elsewhere.
System requirements specification:
1.1 On making a request for a document from LIBSYS. The requestor shall be presented with a form that records details of the user and the request made.
1.2 LIBSYS request form shall be stored on the system for five years from the date of request.
1.3 All LIBSYS request forms must be indexed by user name, the material requested and by the supplier of the request.
1.4 LIBSYS shall maintain a log of all requests that have been made to the system.
1.5 For material where authors’ lending rights apply, loan details shall be sent monthly to copyright licensing agencies that have registered with LIBSYS.

13. Problems with Requirements
Problems arise when requirements are not precisely stated (Ambiguous).
Ambiguous requirements may be interpreted in different ways by developers and users.
Should be complete and consistent.

14. 2. Non-Functional Requirements
System Properties
Reliability, Response time, Maintainability, Storage requirements.
Constraints
I/O device capability, Data representations.
Process Requirements
Mandating a particular CASE system, Programming language or Development method.

15. Types of Non-Functional Requirements

16. Examples of Non-Functional Requirements
Product Requirement:
The user interface for LIBSYS shall be implemented as simple HTML without frames or Java applets.
Organisational Requirement:
The system development process and deliverable documents shall conform to the process and deliverables defined in XYZCo-SP-STAN-95.
External Requirement:
The system shall not disclose any personal information about customers apart from their name and reference number to the operators of the system.

17. Which do you think is more critical, A functional or non-functional requirement? Why?
Question:

18. Verifiable Non-Functional Requirements
Non-functional requirements may be very difficult to state precisely.
Imprecise requirements may be difficult to verify.
Therefore we need a statement using some measure that can be objectively tested.

19. Verifiable Non-Functional Requirements
Example: The system shall be easy to use.
Better expressed as:
Experienced users shall be able to use all the system functions after a total of two hours training. After this training, the average number of errors made by experienced users shall not exceed two per day.

20. Requirements’ Measures
Property
Measure
Speed
Processed transactions/second.
User/Event response time.
Screen refresh time.
Size
M Bytes.
Number of ROM chips.
Ease of use
Training time.
Number of help frames.
Reliability
Mean time to failure.
Probability of unavailability.
Rate of failure occurrence.
Availability.
Robustness
Time to restart after failure.
Percentage of events causing failure.
Probability of data corruption on failure.
Portability
Percentage of target dependent statements.
Number of target systems.

21. Guidelines for writing requirements
Invent a standard format and use it for all requirements.
Use language in a consistent way.
Use shall for mandatory requirements, should for desirable requirements.
Use text highlighting to identify key parts of the requirement.
Avoid the use of computer jargon.

22. Why is it important to get it right?
If you don’t do it right you will build a very elegant software solution that solves the wrong problem.
the result is project failure, wasted time and money, personnel frustration, and customer dissatisfaction.

23. Representing requirements The SRS document
The Software Requirements Specification (SRS) document is the official statement of what is required of the system developers.

24. Representing requirements The SRS document
Should include both:
a definition of user requirements.
a specification of the system requirements.
It is NOT a design document. As far as possible, it should set WHAT the system should do rather than HOW it should do it.

25. Representing requirements Users of the SRS document

26. Structure of the SRS document
Preface.
Introduction.
Glossary.
User requirements definition.
System requirements specification.
System models.
Appendices.
Index.

27. Requirements Engineering Process
“The process of establishing the services that the customer requires from a system and the constraints under which it operates and is developed.”
The result is a specification: “representing the requirements in a manner that ultimately leads to successful software implementation.”

28. Requirements Engineering Process
+ Requirements Management

29. Requirements Engineering Process 1. Feasibility Study
A feasibility study decides whether or not the proposed system is worthwhile.
A short focused study that checks:
If the system contributes to organisational objectives;
If the system can be engineered using current technology and within budget;
If the system can be integrated with other systems that are used.

30. Can you identify possible stakeholders for the LIBSYS?
Requirements Engineering Process 2. Requirements Elicitation
Involves technical staff working with customers to find out about the application domain, the services that the system should provide and the system’s operational constraints.
May involve end-users, managers, engineers involved in maintenance, domain experts, trade unions, etc. These are called stakeholders.
Can you identify possible stakeholders for the LIBSYS?

31. Requirements Engineering Process 2. Requirements Elicitation
Requirements Discovery.
Sources of information:
Documentation.
ex: Existing documents and files (business mission, sample forms, flowcharts, etc…)
System stakeholders by:
Interviews.
Observation (ethnography).
Questioners.
Specifications of similar systems (reports).

32. Requirements Engineering Process 2. Requirements Elicitation
Requirements Analysis (System Models).
The model aids the analyst in understanding the system, thereby makes the requirements analysis easier and more systematic.
The model becomes the focal point of review.
The model becomes foundation for design.
Produced during requirements analysis.

33. Requirements Engineering Process 3. Requirements Specification
It is the final work product produced by the requirements engineer.
The SRS document.
It serves as a foundation for the software design and implementation.

34. Requirements Engineering Process 4. Requirements Validation
The process of ensuring that the requirements actually define the system that the customer wants.
Why is it important?
The cost of fixing a requirements problem by making a system change is much greater than repairing design or coding errors.

35. Requirements Engineering Process 4. Requirements Validation /Checks
Validity checks.
Is this what the user wants?
Consistency checks.
Requirements should not conflict.
Completeness checks.
Requirements should define all functions and constraints.
Realism checks.
Ensure they could be implemented.
Verifiability.
Requirements should be written so that they are verifiable, you should be able to write tests for each requirement.

36. Requirements Engineering Process 4. Requirements Validation /Techniques
Requirements reviews.
A team of reviewers manually check the requirements.
Prototyping.
An executable model of the system is demonstrated to customers.
Test-case generation.
Requirements should be testable. If tests are difficult or impossible to design, this means that the requirements will be difficult to implement.
Developing tests before any code is written is used in ---- ?.

37. Requirements Engineering Process 5. Requirements Management
Why?
Requirements for large software systems are always changing. Because the problem can not be fully specified, the requirements are usually incomplete and bound to change.
During the software process the stakeholders understanding of the problem is constantly changing.
After the system is installed, new requirements will emerge.
What?
It is the process of understanding and controlling changes to system requirements.

38. Requirements Engineering Process 5. Requirements Management (Planning)
Requirements identification.
Each requirement must be uniquely identified.
A change management process.
Assess the impact and cost of change.
Traceability policies.
Define the relationship between requirements.
CASE tool support.

39. Good Requirements Explanation Characteristic
Everything the software is supposed to do and responses of the software to all classes of input data are specified in the SRS.
Complete
The requirement does not contradict any other requirement.
Consistent
Every requirement in the SRS represents something required in the final system.
Correct
The requirement is concisely stated without recourse to technical jargon, acronyms (unless defined elsewhere in the Requirements document. Every requirement has one and only one interpretation.
Unambiguous
There is a cost effective method that can check whether the final software meets the requirement.
Verifiable