Chapter 6 Software Requirements Part - 2

1. Chapter 6Software RequirementsPart - 2

2. 6.3 System requirements • More detailed specifications of user requirements • Serve as abasis for designing the system • May be used as part of the system contract • System requirements may be expressed using system models such as (context, behavioral, data, and object oriented models) • Should statewhat the system should do and not ,how it should be implemented.

3. Requirements and design • In principle, requirements should state what the system should do and the designshould describe how it does this • In practice, requirements and design areinseparable,because of the following: • A system architecture may be initially designed to help in structuring the requirements • The system may inter-operate with other systems that generate design requirements

4. Problems with NL(When used in detailed specification , in system design) • 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 modularization معيار او مقياس • NL structures are inadequate to structure system requirements

5. Alternatives to NL specificationBecause of these problems, requirements specifications written in NL are prone (liable) to misunderstanding. These are often not discovered until later phases which make it very expensive to resolve.There are various alternatives to the use of NL such are structured language specifications and graphical notation.

6. Alternatives to NL specification

7. 6.3.1 Structured language specifications • A limited form of natural language may be used to express requirements. • This removes some of the problems resulting fromambiguityand flexibility and imposes a degree of uniformity on a specification • It may limit the terminology used, and may use one or more standard forms or templates to specify system requirements.

8. This form is used for specifying functional requirements( content of the form)Form-basedapproach 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 • Description of the side effects (if any)

9. Form-based node specification

10. Tabular specification • Used to supplement natural language. • Particularly useful when you have to define a number of possible alternative courses of action. • Example:

11. Graphical models • Graphical models are most useful when you need to show how state changes or where you need to describe a sequence of actions. • Example of graphical model is sequence diagram in the next slide. • 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.

12. Sequence diagram of ATM withdrawal

13. 6.4 Interface specification • Most systems must operate with other systems and the operating interfaces must be specified as part of the requirements • Three types of interface may have to be defined • Procedural interfaces, where existing sub-system offer a range of services. (Called application programming Interface (APIs) • Data structures which are passed from one structure to another. Use the Graphical Data models to represent this type. • Data representation: such as the order of bits. Used in real time embedded system

14. 6.5 The software requirementsdocument • 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 ofWHAT the system should do rather than HOW it should do it

15. TheRequirements Documentshould: • Specify external system behaviour • Specify implementation constraints • should be easy to change • Characterise responses to unexpected events

16. Structure of requirements documentStandardsas suggested by IEEE: • Introduction, purpose of the requirements document, scope of the product, references,overview of the document. • General description, product functions, user chars, general constraints, assumptions and dependencies. • Specific requirements, covering functional, non-functional, and interface requirements. • Appendices • Index • This is a generic structure that must be instantiated for specific systems

17. Requirements document structure • Introduction • Glossary • User requirements definition • System architecture • System requirements specification • System models • System evolution • Appendices • Index, may be several.

18. Key points • 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 are product requirements which constrain the system being developed or the development process • User requirements are high-level statements of what the system should do

19. Key points • User requirements should be written in natural language, tables and diagrams • System requirements are intended to communicate the functions that the system should provide • System requirements may be written in structured natural language, a in a formal language • A software requirements document is the agreed statement of the system requirements. It should be organized so that can be used by both system customers and software developers.