Software requirements

1. Software requirements • Chapter 1 These slides are prepared by EnasNaffar to be used in Software requirements course - Philadelphia university based on the material of "Requirements Engineering" textbook

2. I need a system that … Requirements Analysis Design Implementation Testing Operation & maintenance

3. What is a Software Requirement? • Software capability needed by the user to solve a problem to achieve an objective [Dorfman] • System Requirements define what the system is required to do and the constraints under which it is required to operate [Sommerville] • Software capability that must be met or possessed by a system…to satisfy a contract, standard, specification, or other formally imposed documentation [Dorfman] • (1) A characteristic that a system or software item is required to possess in order to be acceptable to the acquirer. (2) A binding statement… Requirements are expressed using the word “shall”. [IEEE/EIA J-STD-016]

4. Introduction to Requirements • Fast-changing technology and increased competition are placing ever increasing pressure on the development process. • Requirements are the basis for every project, defining what the stakeholders –users, customers, suppliers, developers, businesses – in a potential new system need from it and also what the system must do in order to satisfy that need.

5. Introduction to Requirements • Once communicated and agreed, requirements drive the project activity. • Agreed requirements provide the basis for planning the development of a system and accepting it on completion. • They are essential when sensible and informed tradeoffs have to be made and they are also vital when changes are requested during the development process.

6. Introduction to Requirements • Requirements form the basis for: • Project planning • Risk management • Acceptance testing • Change control

7. Introduction to Requirements • What reasons could cause a project to fail? • Incomplete requirements 13.1% • Lack of user involvement 12.4% • Lack of resources 10.6% • Unrealistic expectations 9.9% • Lack of executive support 9.3% • Changing requirements/specification 8.7% • Lack of planning 8.1% • Didn’t need it any longer 7.5%

8. Introduction to Requirements • Project success factors • User involvement 15.9% • Management support 13.9% • Clear statement of requirements 13.0% • Proper planning 9.6% • Realistic expectations 8.2% • Smaller milestones 7.7% • Competent staff 7.2% • Ownership 5.3%

9. Introduction to Systems Engineering • What then do we mean by a “system”? • A system is a: • • collection of components – machine, software and human – • • which cooperate in an organized way – • • to achieve some desired result – the requirements. • To understand the requirements of a system properly, we should understand its enclosing system.

10. Introduction to Systems Engineering • Consider a railway system. What are the components of this system?

11. Introduction to Systems Engineering

12. Introduction to Systems Engineering 12 • The engineering of requirements must take the nature of systems into account. • Essential considerations are emergent properties, the constraints and provisions of the external environment and the interfaces with surrounding systems.

13. Requirements and Quality • Quality is “fitness for purpose” or conformance to requirements – it is providing something that satisfies the customer and in doing so ensures that the needs of all the stakeholders are taken into account.

14. Requirements and Quality • Goal of software development is to develop quality software–on time and on budget–that meets customer’s real needs • Project success depends on effective requirements management • Requirements error are the most common type of systems development errors and the most costly to fix • A few key skills can significantly reduce requirements errors and thus improve software quality

15. Requirements and Quality • There are lots of evidences around us of systems that failed because requirements were not properly organized. • Even if the system works, it is useless if it doesn’t meet users’ requirements. • Improving requirements means improving the quality of the product.

16. REQUIREMENTS AND THE LIFECYCLE • There is a common misconception that requirements engineering is just a single phase that is carried out and completed at the outset of product development. • Requirements engineering has a vital role to play at every stage of development. • As an initial approach, consider one of the very last activities in the development process: acceptance testing. What is a system accepted against? – the stakeholder requirements.

17. REQUIREMENTS AND THE LIFECYCLE • The classic V-model, which is used to depict the various stages of development, has its basis in this relationship between testing and requirements

18. REQUIREMENTS AND THE LIFECYCLE • Without effective requirements engineering, development projects are like ships drifting rudderless in a storm! • Above all else, with good requirements management, hearing the voice of the users and customers becomes a matter of clear lines of communication throughout the development process.

19. REQUIREMENTS AND THE LIFECYCLE • Another role that requirements can play in an organization is to act as a means of communicating between projects. • This is a good idea, because many organizations wish to: • • maximize reuse of artifacts across projects; • • manage families of similar products; • • optimize process by learning from the experiences of other projects;

20. REQUIREMENTS AND THE LIFECYCLE • A good set of stakeholder requirements can provide a concise, non-technical description of what is being developed at a level that is accessible to senior management. • Similarly, the system requirements can form an excellent technical summary of a development project.

21. REQUIREMENTS AND THE LIFECYCLE • If requirements are to play such a central role in systems development, they need to be maintained. • To change the design of a product without having also updated the requirements to reflect that change is to store up huge problems for later stages of development. • Hence requirements engineering connects strongly with change management.

22. REQUIREMENTS AND THE LIFECYCLE • The impact of that change on quality, cost and schedule needs to be assessed. • This assessment forms the basis on which to: • • accept or reject the change (where that is a choice); • • negotiate the cost of the change with the customer/suppliers; • • organize the redevelopment work.

23. REQUIREMENTS TRACEABILITY • In the requirements engineering context, traceability is about understanding how high-level requirements – objectives, goals, aims, aspirations, expectations, needs – are transformed into low-level requirements.

24. REQUIREMENTS TRACEABILITY • In a business context, one may be interested in how • • business vision is interpreted asbusiness objectives are implemented asbusiness organization and processes. • In an engineering context, the interest may focus on how • • stakeholder requirements are met by system requirements are partitioned into subsystemsare implemented ascomponents.

25. REQUIREMENTS TRACEABILITY • Using traceability can contribute to the following benefits: • Greater confidence in meeting objectives. • Ability to assess the impact of change. • • Ability to track progress. • • Ability to balance cost against benefit.

26. REQUIREMENTS TRACEABILITY • Traceability relationships are usually many-to-many – that is, one lower level requirement may be linked to several higher level requirements and vice versa.

27. REQUIREMENTS TRACEABILITY • Requirements management tools typically allow such linking by drag-and-drop between paragraphs of documents. • The links are rather like hyperlinks in web pages, but should ideally be traversable in either direction.

28. REQUIREMENTS AND MODELLING The systems engineering sandwich.

29. REQUIREMENTS AND MODELLING • They are mutually supportive activities that should not be equated. • The requirements themselves are a complete snapshot of what is required at each level in increasing levels of detail. • A particular model never says everything about a system – if it did, it would not be a model.

30. REQUIREMENTS AND MODELLING • Models assist the requirements engineer in analyzing the requirements at a particular level so as to: • • Communicate with the customer and improve mutual understanding of the system to be developed; • • Analyze the system to ascertain the presence of desired emergent properties (and the absence of undesirable ones); • • Determine how to satisfy the requirements by deriving new requirements at the layer below.

31. REQUIREMENTS AND TESTING • Testing is any activity that allows defects in the system to be detected or prevented, where a defect is a departure from requirements. • Testing is closely related to requirements at every level.

32. Requirements and Testing • Testing activities include reviews, inspections, analysis through modeling in addition to the classical tests of components, subsystem and systems that are carried out. • Qualification should begin as early as possible, since waiting until the system is almost complete before carrying out any kind of testing can lead to very expensive design changes and rebuilds.

33. REQUIREMENTS IN THE PROBLEM AND SOLUTION DOMAINS

34. REQUIREMENTS IN THE PROBLEM AND SOLUTION DOMAINS Needs – in user terms Problem Domain Features – a service provided by the system that fulfills a need Software requirements – more specific Solution Domain 34

35. REQUIREMENTS IN THE PROBLEM AND SOLUTION DOMAINS Consider an online bookstore to compete with Amazon. Example of a feature: Click Ordering Examples of requirements related to this feature: User shall be able to activate 1-click ordering within his account User shall be able to deactivate 1-click ordering within his account User shall be able to order books with just 1 click … User shall be able to “Undo” his 1-click order for a period of 30 minutes from the time he placed such an order 35

36. REQUIREMENTS IN THE PROBLEM AND SOLUTION DOMAINS • Without a clear distinction between problem and solution, the following may result: • • lack of understanding of the real problem; • • inability to scope the system and understand which functions to include; • domination of debate about the system by the developers and suppliers, because the only descriptions of the system are expressed in terms of solutions; • • inability to find optimal solutions due to lack of design freedom.