1. Chapter 4 Software Requirements
Chapter 6,and 7 in textbook 1

2. Objectives To understand the concept of software requirements
To understand the difference between functional and non functional requirements
Understand the importance of getting it right.
Understand how requirements are documented (the SRS document) 2

3. Overview What are software requirements? User and system requirements
Functional requirements
Non functional requirements
Domain requirements
User and system requirements
Interface specification
Why is it important to get it right?
The SRS document 3

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. 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.

6. Requirements types Functional requirements Non-functional requirements
Domain requirements

7. Functional Requirements

8. Functional Requirements
Describe functionality or system services.
Depend on the type of software, expected users and the type of system where the software is used.
Functional requirements can be
User requirements:
high-level statements of system functionality
System requirements:
describe the system services in detail.

9. User requirements- examples
The user shall be able to search either all of the initial set of databases or select a subset from it.
The user shall be able to order any book by company xyz.

10. Problems
Problems arise when requirements are not precisely stated (Ambiguous)
Ambiguous requirements may be interpreted in different ways by developers and users.

11. Non-Functional Requirements

12. Non-Functional Requirements
These define system properties, constraints, and process requirements

13. System Properties Reliability, Response time Maintainability
Storage requirements.

14. Constraints I/O device capability,
Data representations used in system interfaces

15. Process Requirements Mandating a particular CASE system,
Programming language or
Development method.

16. Which do you think is more critical, A functional or non-functional requirement and why? Have a look at the following video
Non-functional requirements may be more critical than functional requirements. If these are not met, the system is useless. If an aircraft does not provide its reliability requirement it will not be certified as safe for operation.

17. Europeana Project

18. Types of Non-functional requirements

19. Examples Product requirement Organisational 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.

20. 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.

21. 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.

22. Requirements measures

23. Domain Requirments

24. Domain Requirements
Derived from the application domain and describe system characteristics and features that reflect the domain.
Domain requirements may be new functional requirements, constraints on existing requirements or define specific computations.

25. Example The deceleration of the train shall be computed as:
Dtrain = Dcontrol + Dgradient
where Dgradient is 9.81ms2 * compensated gradient/alpha and where the values of 9.81ms2 /alpha are known for different types of train.

26. Class Activity
Working with your team, identify the type of requirements listed on the sheet.
When you are done discuss your decisions with the rest of the class.
Check each requirement, if you got it right give yourself 1 point.
Compute your total.
The winning teams will get a smiley sticker

27. User and System Requirements

28. We provide a definition for a user requirement.
User 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.
We provide a definition for a user requirement.

29. We provide a specification for a system requirement.
System Requirements
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 specification for a system requirement.

30. 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.

31. Definition and Specifications

32. Interface Specification
Most systems must operate with other systems and the operating interfaces must be specified as part of the requirements.

33. The SRS document

34. 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.

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

36. The SRS document Should include both
a definition of user requirements and
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.

37. Users of the SRS

38. Structure of the SRS Preface Introduction Glossary
User requirements definition
System architecture (high level)
System requirements specification
System models
System evolution
Appendices
Index

39. Requirments Engineering

40. 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.

41. Requirements engineering
Involves the following processes
Feasibility Study  Feasibility Report
Requirements elicitation  System Models
Requirements Specification  user and system requirements
Requirements validation  Requirements document (SRS)
+ Requirements Management

42. Requirements Engineering Process

43. The 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.

44. 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, etc. These are called stakeholders.

45. Requirements discovery
Sources of information
Documentation
System stakeholders
Interviews
Observation (ethnography)
Specifications of similar systems

46. Stakeholders for LIBSYS
Can you identify possible stakeholders for the LIBSYS?
Library manager
Article providers
Students
Staff

47. Analysis : System models
Why?
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.
More on modeling in chapter 5.

48. 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.

49. 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.

50. Validation checks Validity checks Consistency 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.

51. 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 ----?

52. 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.

53. 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

54. 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