1. Software Requirements Analysis and Specification

2. Topics covered Functional and non-functional requirements
User requirements
System requirements
The software requirements document

4. Requirements engineering
The process of establishing the services that the customer requires from a system and the constraints under which it operates and is developed.
The requirements themselves are the descriptions of the system services and constraints that are generated during the requirements engineering process.

5. What is a requirement?
It may range from a high-level abstract statement of a service or of a system constraint to a detailed mathematical functional specification.
This is inevitable as requirements may serve a dual function
May be the basis for a bid for a contract - therefore must be open to interpretation;
May be the basis for the contract itself - therefore must be defined in detail;
Both these statements may be called requirements.

6. Requirements Engineering Components
SW Eng of Standalone Programs, Req Analysis & Specification
Rev. 09/09/06
Requirements Engineering Components
Requirements Engineering
Requirements Elicitation
Requirements Analysis
Requirements Verification
Requirements Specification
These are the five activities involved in sw req engineering.
Requirements Management
ECEN5543, University of Colorado, Boulder

7. Requirements Engineering
Requirements Elicitation : the task of communicating with customers and users to determine what their requirements are. This is sometimes also called requirements gathering.
Requirements Analysis : determining whether the stated requirements are unclear, incomplete, ambiguous, or contradictory, and then resolving these issues.
Requirements Specification : documenting the system requirements in a semiformal or formal manner to ensure clarity, consistency, and completeness.
Requirements might be documented in various forms, such as natural-language documents, use cases, user stories, or process specifications.

8. Eliciting Requirements
Helps the customer to define what is required: what is to be accomplished, how the system will fit into the needs of the business, and how the system will be used on a day-to-day basis
Analysts can employ several techniques to elicit the requirements from the customer.
interviews,
focus groups (requirements workshops) and creating requirements lists.
prototyping, and use cases.
combination of these methods

9. Software Requirement Analysis
In other words, process of studying and analyzing the customer and the user/stakeholder needs to arrive at a definition of software requirements.
Requirements must be actionable, measurable, testable, related to identified business needs or opportunities, and defined to a level of detail sufficient for system design.
Requirements can be functional and non-functional.

10. Requirements Analysis
Defining Stakeholder and User profiles
Description - brief description of the stakeholder/user type
Type - Qualify user’s/s-h’s expertise, technical background, degree of sophistication
Responsibilities - List user’s/s-h’s key responsibilities with regard to the system being developed - why a stakeholder?
Success Criteria - How does the user/stakeholder define success? How rewarded?
Involvement - involved in the project in what way? What role? Requirements reviewer, system tester, ...
Deliverables - Are there any deliverables the user produces? For whom? Any required by stakeholder?
Comments/Issues - Problems that interfere with success, etc.
This includes trends that make the user’s job easier or harder

11. Requirements Analysis
Defining User Work Environment
Number of people involved in doing this now? Changing?
How long is a task cycle now? Changing?
Any unique environmental constraints: mobile, outdoors, in-flight, etc.
Which system platforms are in use today? future?
What other applications are in use? Need to integrate?

12. Requirements Analysis
Product Overview Put the product in perspective to other related products and the user’s environment. Independent? Component of a larger system? How do the subsystems interact with this? Known interfaces between them and this component? Block diagram

13. Requirements Analysis
Other Product Requirements
hardware platform requirements --
system requirements -- supported host o.s.’s, peripherals, companion software
environmental requirements -- temperature, shock, humidity, radiation, usage conditions, resource availability, maintenance issues, type of error recovery
applicable standards -- legal, regulatory, communications

14. Types of requirement User requirements System requirements
Statements in natural language plus diagrams of the services the system provides and its operational constraints. Written for customers.
System requirements
A structured document setting 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.

15. Requirements vs. Design
Describe what will be delivered
Describe how it will be done3
Primary goal of analysis:
UNDERSTANDING
Primary goal of design:
OPTIMIZATION
There is more than one solution
There is only one (final) solution
Customer interested
Customer not interested (Most of the time) except for external

16. Requirements and design
In principle, requirements should state what the system should do and the design should describe how it does this.
In practice, requirements and design are inseparable
A system architecture may be designed to structure the requirements;
The system may inter-operate with other systems that generate design requirements;
The use of a specific design may be a domain requirement.

17. Functional and non-functional requirements
Functional requirements describe system behaviors. Statements of services the system should provide, how the system should react to particular inputs and how the system should behave in particular situations.
Priority: rank order the features wanted in importance
Criticality: how essential is each requirement to the overall system?
Risks: when might a requirement not be satisfied? What can be done to reduce this risk?

18. Functional and non-functional requirements
Non-functional requirements describe other desired attributes of overall system—constraints on the services or functions offered by the system such as timing constraints, constraints on the development process, standards, etc.
Product cost (how do measure cost?)
Performance (efficiency, response time? startup time?)
Portability (target platforms?), binary or byte-code compatibility?
Availability (how much down time is acceptable?)
Security (can it prevent intrusion?)
Safety (can it avoid damage to people or environment?)
Maintainability (in OO context: extensibility, reusability)
Non-functional requirements may be more critical than functional requirements. If these are not met, the system is useless.

19. FURPS+ model (Grady 1992) FURPS is a checklist for requirements:
Functional (features, capabilities, security)
Usability (human factors, help, documentation)
Reliability (frequency of failure, recoverability, predictability)
Performance (response time, throughput, accuracy, availability, resource usage)
Supportability (adaptability, maintainability, internationalization, configurability)

20. What’s with the + in FURPS+?
And don’t forget….
Implementation (resource limitation, language and tools, hardware)
Interface (constraints posed by interfacing with external systems)
Operations (system management in its operational setting)
Packaging (for example, a physical box)
Legal (licensing)

21. The LIBSYS system
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.

22. Examples of functional requirements
The user shall be able to search either all of the initial set of databases or select a subset from it.
The system shall provide appropriate viewers for the user to read documents in the document store.
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.

23. Requirements imprecision
Problems arise when requirements are not precisely stated.
Ambiguous requirements may be interpreted in different ways by developers and users.
Consider the term ‘appropriate viewers’
User intention - special purpose viewer for each different document type;
Developer interpretation - Provide a text viewer that shows the contents of the document.

24. Requirements completeness and consistency
In principle, requirements should be both complete and consistent.
Complete
They should include descriptions of all facilities required.
Consistent
There should be no conflicts or contradictions in the descriptions of the system facilities.
In practice, it is impossible to produce a complete and consistent requirements document.

25. Non-functional classifications
Product requirements
Requirements which specify that the delivered product must behave in a particular way e.g. execution speed, reliability, etc.
Organisational requirements
Requirements which are a consequence of organisational policies and procedures e.g. process standards used, implementation requirements, etc.
External requirements
Requirements which arise from factors which are external to the system and its development process e.g. interoperability requirements, legislative requirements, etc.

26. Non-functional requirement types

27. Non-functional requirements examples
Product requirement
8.1 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.
A system goal
The system should be easy to use by experienced controllers and should be organised in such a way that user errors are minimised.
A verifiable non-functional requirement
Experienced controllers 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.

28. Requirements interaction
Conflicts between different non-functional requirements are common in complex systems.
Spacecraft system
To minimise weight, the number of separate chips in the system should be minimised.
To minimise power consumption, lower power chips should be used.
However, using low power chips may mean that more chips have to be used. Which is the most critical requirement?

29. Domain requirements
Derived from the application domain and describe system characteristics and features that reflect the domain.
Domain requirements be new functional requirements, constraints on existing requirements or define specific computations.
If domain requirements are not satisfied, the system may be unworkable.

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

31. User requirements
Should describe functional and non-functional requirements in such a way that they are understandable by system users who don’t have detailed technical knowledge.
User requirements are defined using natural language, tables and diagrams as these can be understood by all users.

32. LIBSYS requirement example
4..5 LIBSYS shall provide a financial accounting system that maintains records of all payments made by users of the system. System managers may configure this system so that regular users may receive discounted rates.

33. System requirements
More detailed specifications of system functions, services and constraints than user requirements.
They are intended to be a basis for designing the system.
They may be incorporated into the system contract.

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

35. Problems with natural language
Lack of clarity
Precision is difficult without making the document difficult to read.
Requirements confusion
Functional and non-functional requirements tend to be mixed-up.
Requirements amalgamation
Several different requirements may be expressed together.

36. Alternatives to NL specification
Structured natural language – this approach depends on defining standard forms or templates to express the requirements specification
Tabular specification - Used to supplement natural language.
Particularly useful when you have to define a number of possible alternative courses of action.
Graphical notations - most useful when you need to show how state changes or where you need to describe a sequence of actions.
Now use-case descriptions and sequence diagrams are commonly used.
Mathematical specifications – notations based on mathematical concepts.
These unambiguous specifications reduce the arguments between customer and contractor about system functionality. However, most customers don’t understand formal specifications and are reluctant to accept it as a system contract.

37. Sequence diagrams
These show the sequence of events that take place during some user interaction with a system.
You read them from top to bottom to see the order of the actions that take place.
Cash withdrawal from an ATM
Validate card;
Handle request;
Complete transaction.

38. Sequence diagram of ATM withdrawal

39. Use Case
use case is a description of a system’s behavior as it responds to a request that originates from outside of that system.
it describes "who" can do "what" with the system in question

40. Use Case Diagram A use case diagram The main purpose
in the Unified Modeling Language (UML)
a type of behavioral diagram defined by and created from a Use-case analysis.
Its purpose is to present a graphical overview of the functionality provided by a system in terms of actors, their goals (represented as use cases), and any dependencies between those use cases.
The main purpose
to show what system functions are performed for which actor.
Roles of the actors in the system can be depicted.

41. Use Case Diagram

42. Software Requirement Specification
A software requirements specification (SRS) is a complete description of the behavior of the system to be developed
A document that clearly and precisely describes, each of the essential requirements of the software and the external interfaces.
(functions, performance, design constraint, and quality attributes)
Each requirement is defined in such a way that its achievement is capable of being objectively verified by a prescribed method; for example inspection, demonstration, analysis, or test.

43. The requirements document
The requirements document is the official statement of what is required of the system developers
Should include both a definition and a specification of requirements
It is NOT a design document. As far as possible, it should set off WHAT the system should do rather than HOW it should do it

44. Requirements document requirements
Specify external system behaviour
Specify implementation constraints
Easy to change
Serve as reference tool for maintenance
Record forethought about the life cycle of the system i.e. predict changes
Characterise responses to unexpected events

45. Desiderata for a requirements specification
Should say what, not how. Why?
Correct: does what the client wants, according to specification
Ask the client: keep a list of questions for the client
Prototyping: explore risky aspects of the system with client
Verifiable: can determine whether requirements have been met
But how do verify a requirement like “user-friendly” or “it should never crash”?
Unambiguous: every requirement has only one interpretation
Consistent: no internal conflicts
If you call an input "Start and Stop" in one place, don't call it "Start/Stop" in another
Complete: has everything designers need to create the software
Understandable: stakeholders understand enough to buy into it
Modifiable: requirements change!
Changes should be noted and agreed upon, in the spec!

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

47. Users of a requirements document

48. IEEE requirements standard
Introduction
General description
Specific requirements
Appendices
Index
This is a generic structure that must be instantiated for specific systems

49. Requirements document structure
Introduction
Glossary
User requirements definition
System architecture
System requirements specification
System models
System evolution
Appendices
Index

50. Summary
Requirements set out what the system should do and define constraints on its operation and implementation.
Functional requirements set out services the system should provide.
Non-functional requirements constrain the system being developed or the development process.
User requirements are high-level statements of what the system should do. User requirements should be written using natural language, tables and diagrams.

51. Summary
System requirements are intended to communicate the functions that the system should provide.
A software requirements document is an agreed statement of the system requirements.
The IEEE standard is a useful starting point for defining more detailed specific requirements standards.