1. REQUIREMENTS ENGINEERING

2. What is a requirement?
Descriptions of the services provided by the system and its operational constraints.
Reflects the needs of customers for a system.
May be…
A high level, abstract statement of a service that the system should provide
A constraint on the system
A detailed formal definiton of a system function.

3. Requirements engineering
The process of finding out, analysing, documenting and checking these services and constraints.

4. Types of requirements User requirements:
high-level abstract requirements
Statements of what services the system is expected to provide and the constraints under which it must operate.
System requirements:
The detailed description of what the system should do
Set out the system’s func., services and operational constraints in detail.

5. Types of requirements cont.
User requirements may be expanded into several system requirements by adding detail, explaining the services and functions.
Requirements should be written at different levels of detail because of different readers.

6. Functional and nonfunctional requirements
Statements of services the system should provide, how the system should react to particular inputs and how the system should behave in particular situations.
Non-functional requirements
constraints on the services or functions offered by the system such as timing constraints, constraints on the development process, standards, etc.
Domain requirements
Requirements that come from the application domain of the system and that reflect characteristics of that domain.

7. Functional requirements
Describe the system function in detail, its input and outputs, exceptions etc.
Depends on…
The type of software
The expected users of the software
The specification of the functional requirements should be complete and consistent.

8. Nonfunctional requirements
May relate to reliability, response time and store occupancy.
Constraints are I/O device capability, system representations, etc.
May specify performance security and availability. So more critical than individual functional requirements.
Failing to meet can mean the whole system is unusable.

9. Types of nonfunctional requirements
Product req. Specify product behavior
Performance, reliability, portability, usability
Organisational req.
Process standards, implementation, delivery
External req.
Interoperability, legislative, ethical

10. Examples Functional requirement: Nonfunctional requirement:
“The customer must place an order within two minutes of registering.”
Nonfunctional requirement:
“The customer must be able to access their account 24 hours a day, seven days a week.”

11. 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.
If domain requirements are not satisfied, the system may be unworkable.

12. Domain requirements example
Tolerance level of landing gear on an aircraft (different on dirt, asphalt, water), or what happens to fiber optics line in case of sever weather during winter Olympics (Only domain-area experts know)

13. Domain requirements problems
Understandability
Requirements are expressed in the language of the application domain;
This is often not understood by software engineers developing the system.
Implicitness
Domain specialists understand the area so well that they do not think of making the domain requirements explicit.

14. User requirements
Should describe the functional and nonfunctional requirements.
Should only specify the external behavior of the system.
System design characteristics, software jargon, structured or formal notations, system implementation should be excluded.
Should be written in simple language.

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

16. System requirements Expanded version of user req.
Describe the external behavior of the system and its operational constraints.
Must not include how the system designed and implemented.

17. Problems with NL specification
Ambiguity
The readers and writers of the requirement must interpret the same words in the same way. NL is naturally ambiguous so this is very difficult.
Over-flexibility
The same thing may be said in a number of different ways in the specification.
Lack of modularisation
NL structures are inadequate to structure system requirements.

18. Structured language specifications
Limits the terminology that can be used and use templates to specify system req. System req. May be specified by:
Using forms
Using tables
Using graphical models

19. Form-based specifications
Definition of the function or entity.
Description of inputs and where they come from.
Description of outputs and where they go to.
Indication of other entities required.
Pre and post conditions (if appropriate).
The side effects (if any) of the function.

20. Form based specification example
ECLIPSE/Workstation/Tools/DE/FS/3.5.1
Function: Add node
Description: Adds a node to an existing design.
Inputs: Node type, Node Position
Outputs: Design identifier
Pre/Post conditions:
Other attributes:
Definition: ECLIPSE/Workstation/Tools/DE/RD/3.5.1

21. Structured lang. specification cont.
By using formatted specification variability is reduced and req. are organised more efficiently.
When complex requirements are needed tables or graphical models can be used.
Use tables when there are a number of possible alternative situations.
Use graphical models when you need to show how state changes or describe a sequence of actions.

22. The requirements document
SRS (software requirement specification) is the official statement of what the system developers should implement
Includes both user requirements and detailed specification of the system requirements.

23. The requirements document cont.
Has a diverse set of users
the req. document has to be a compromise between communicating the requirement to customers, defining them in precise detail for developers and testers and including information about possible system evolution.
The level of detail depends on the type of system that is being developed and the development process used.
External contractor: very detailed
Iterative development process: less detailed

24. IEEE requirements standard
Defines a generic structure for a requirements document that must be instantiated for each specific system.
Introduction.
General description.
Specific requirements.
Appendices.
Index.

25. Feasibility studies
A feasibility study decides whether or not the proposed system is worthwhile.
Inputs: List of business requirements, system description, how the system improve business
Outputs: Answer of the question “Should we do this development?”

26. Elicitation and analysis
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.
STAKEHOLDER: End-users, managers, engineers involved in maintenance, domain experts, trade unions, etc.
Shortly; people affected by the system directly or indirectly.

27. Requirements discovery
The process of gathering information about the proposed and existing systems and distilling the user and system requirements from this information.
This information comes from documentation, system stakeholders and the specifications of similar systems.

28. Registration.boun.edu.tr
Who are stakeholders?

29. Interviewing
In formal or informal interviewing, the Requirements Engineering team puts questions to stakeholders about the system that they use and the system to be developed.
There are two types of interview
Closed interviews where a pre-defined set of questions are answered.
Open interviews where there is no pre-defined agenda and a range of issues are explored with stakeholders.

30. Scenarios
Scenarios are real-life examples of how a system can be used.
They should include
A description of the starting situation;
A description of the normal flow of events;
A description of what can go wrong;
Information about other concurrent activities;
A description of the state when the scenario finishes.

31. Registration scenario

32. Use cases
Use-cases are a scenario based technique in the UML which identify the actors in an interaction and which describe the interaction itself.
A set of use cases should describe all possible interactions with the system.
Sequence diagrams may be used to add detail to use-cases by showing the sequence of event processing in the system.

33. Registration use cases
Drop course
Add course
Consent Requests
Registration
Office
Course scheduling
Student
Instructor

34. Add CMPE 352 Student course Cmpe 352 Instructor Ayse Basar Bener
request
acquired
Regs system :
BOUNsystem
RegsPage
Mypage
return
Add OK
Inform available
Add available
Add
confirm
inform

35. Ethnography
A social scientists spends a considerable time observing and analysing how people actually work.
Social and organisational factors of importance may be observed.
Ethnographic studies have shown that work is usually richer and more complex than suggested by simple system models.
Requirements that are derived from the way that people actually work rather than the way which process definitions suggest that they ought to work. Reality!!!
Requirements that are derived from cooperation and awareness of other people’s activities.

36. Requirements validation
Concerned to validate that the requirements define the system that the customer really wants.
Requirements error costs are high so validation is very important
Fixing a requirement error before completing project or delivering it is much more cheaper...

37. Requirements checking
Validity. Does the system provide the functions which best support the customer’s needs?
Consistency. Are there any requirements conflicts?
Completeness. Are all functions required by the customer included?
Realism. Can the requirements be implemented given available budget and technology
Verifiability. Can the requirements be checked?

38. Requirements management
Requirements management is the process of managing changing requirements during the requirements engineering process and system development.
Requirements are inevitably incomplete and inconsistent
There will be always requirements during the process as business needs change and a better understanding of the system is developed;
Different viewpoints have different requirements and these are often contradictory; Students do not want to take courses starting at 09.00am, Instructors do not want to come to school everyday.

39. Requirements change management
Should apply to all proposed changes to the requirements.
Principal stages
Problem analysis. Discuss requirements problem and propose change;
Change analysis and costing. Assess effects of change on other requirements;
Change implementation. Modify requirements document and other documents to reflect change.

40. References Ian Sommerville, Software Engineering
Deriving Tabular Event-Based Specifications
from Goal-Oriented Requirements Models - Renaud De Landtsheer, Emmanuel Letier and Axel van Lamsweerde
Bahill A.T. And Dean F.F., Handbook of Systems Engineering and Management