Chapter 4 Software Requirements

1. Chapter 4Software 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? • 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

17. Europeana Project

18. Types of Non-functional requirements

19. Examples • Product 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 Dgradientis 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. 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. 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 • 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.