Software Requirements

1. Software Requirements • Specifying system functionality and constraints • Chapters 5 and 6 ++

2. Requirements engineering • Requirements engineering (or requirements analysis) is the process of establishing: • the services that the customer requires from a system • the constraints under which it operates and is developed • A requirement may range from a high-level abstract statement of a service or constraint to a detailed mathematical expression • Failure here is a major cause of software development failures.

3. Types of requirements • User requirements • statements in natural language plus diagrams • written for customers • System requirements • detailed, structured descriptions of system services • written as a contract between client and contractor • Software design specification • even more detail – can serve as a basis for a design • written for developers

4. Requirement classification • Functional requirements • statements of services the system should provide • they describe how the system should react to particular inputs and how it should behave in particular situations • might include user interface issues • Constraints • constraints on the services offered by the system • timing constraints, standards, development processes

5. Functional requirements examples • The user shall be able to search either all of the initial set of databases or select a subset from that set to search. • The system shall provide the viewers listed in Appendix B: Supported Viewer Software, for the user to read documents in the document store. • Every order shall be allocated a unique identifier which the user shall be able to copy to the account’s permanent storage area.

6. Process activities • Domain understanding • Requirements discovery or elicitation • Analysis and conflict resolution • Classification, Prioritization • Specification • Verification

7. Requirements Discovery • 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 various stakeholders: end-users, managers, engineers involved in maintenance, domain experts, trade unions, etc.

8. Why is it difficult? • Client doesn’t know what they really want • Client underestimates importance • Client makes assumptions • Producer not familiar with application area • Different stakeholders may have conflicting requirements • Difficult client/producer chemistry • The requirements change during the analysis process

9. Be wary of runaway requirements • Do not allow scope creep • Be aware of “kitchen sink” user approach • Elicit justification of requirements • Reject if not plausible or cost/benefit high

10. Methods of Discovery Should use a well-defined methodical approach: • Introspection • Elicitation • Interviews • Observation (Ethnography) • Protocol Analysis • Viewpoint Oriented • Prototypes

11. The requirements document • The requirements document is the official statement of what is required of the system developers • It is read by a variety of stakeholders (people interested in the system and its development) • It is not a design document • As much as possible, it should specify what the system should do rather than how it should do it

12. IEEE requirements standard • Defines a generic structure for a requirements specification: • Introduction • Purpose, Scope, Definitions, References, Overview • General description • Perspective, Functions, User, Constraints • Specific requirements • Appendices • Index

13. Specific Requirements (IEEE) • Include functional, interface, performance, design constraints, quality attributes, etc. • Each functional should include • overview • inputs • processing • outputs • exceptions

14. Alternatives to natural language • Structured natural language • standard templates • Program design language (PDL) • like a programming language, but more abstract • Graphical notation • diagrams with text annotations • Mathematical specification • formal and precise (ex: finite state machine)

15. Form-based specification

16. Structured presentation

17. The VORD process model • Viewpoint identification • Viewpoint structuring • Viewpoint documentation • Viewpoint-system mapping

18. Scenarios • Scenarios are descriptions of how a system is used in practice • They are helpful in requirements elicitation as people can relate to these more readily than abstract statement of what they require from a system • Scenarios can be included in a user oriented requirements document.

19. Scenario descriptions • The description of a scenario includes: • System state at the beginning of the scenario • Normal flow of events in the scenario • What can go wrong and how this is handled • Other concurrent activities • System state on completion of the scenario

20. Use cases • Use cases are a scenario-based technique in 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

21. Catalog management

22. Desirable Properties of the SRSand of requirements themselves • Usable • Complete and Consistent • Well structured • Traceable and Verifiable • Annotated in appropriate ways • Good technical writing used

23. Usable • Correct! • Understandable • Achievable • Design Independent • At Right Level of Detail

24. Complete and Consistent • 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 • In practice, for large systems, it is almost impossible to produce a complete and consistent requirements document

25. Well Structured • Standard organization • Modifiable • Layout • Limit Redundancy • Indexed (automated?)

26. Traceable • Traceability is concerned with the relationships between requirements, their sources and the design • Source traceability • Links from requirements to stakeholders who proposed these requirements • Requirements traceability • Links between dependent requirements • Design traceability • Design Document can reference the requirements separately

27. Verifiable • Goals can be fuzzy. Requirements should not be. There should exist a finite, cost-effective way to check each one. • A system goal • The system should be easy to use by experienced controllers and should be organized in such a way that user errors are minimized. • 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 shall not exceed two per day. • Defining verifiable requirements can be difficult.

28. Requirements measures

29. Annotated Appropriately • by relative importance • must, should, could • by relative stability • by version

30. Use Good Technical Writing • Unambiguous • Concise • and so on …..