Introduction to Software Requirements

1. Introduction to Software Requirements Dr Suad AlRamouni

2. Learning Outcomes • Understand some key terms used in software requirements engineering. • Distinguish requirements development from requirements management. • Be alert to some requirements-related problems that can arise. • Learn several characteristics of excellent requirement

3. Why Software projects fail? • Lack of user input, incomplete requirements, and changing requirements are the major reasons why so many information technology projects fail to deliver all of their planned functionality on schedule and within budget • Many software developers aren’t comfortable or proficient at gathering requirements from customers. • Customers often don’t have the patience to participate in requirements development, or they have the wrong people supply the requirements

4. Project participants often don’t even agree on what a "requirement" is? • Software development involves at least as much communication as computing, yet we often emphasize the computing and neglect the communication.

5. Case Study

6. Part I. Software Requirements: What, Why, and Who • The Essential Software Requirement • Many software problems arise from shortcomings in the ways that people gather, document, agree on, and modify the product’s requirements. As with Phil and Maria, the problem areas might include informal information gathering, implied functionality, erroneous or uncommunicated assumptions, inadequately defined requirements, and a casual change process

7. Bad Requirements Costs! • Errors made during the requirements stage account for 40 to 60 percent of all defects found in a software project • The two most frequently reported problems in a large survey of the European software industry concerned specifying and managing customer requirements.

8. Nonetheless, many organizations still practice ineffective methods for these essential project activities. The typical outcome is an expectation gap, a difference between what developers think they are supposed to build and what customers really need.

9. Stakeholders • Nowhere more than in the requirements process do the interests of all the stakeholders in a software or system project intersect. These stakeholders include • Customers who fund a project or acquire a product to satisfy their organization’s business objectives. • Users who interact directly or indirectly with the product (a subclass of customers) • Requirements analysts who write the requirements and communicate them to the development community.

10. Developers who design, implement, and maintain the product. • Testers who determines whether the product behaves as intended. • Documentation writers who produce user manuals, training materials, and help systems. • Project ne whether the product behaves as managers who plan the project and guide the development team to a successful delivery.

11. Legal staff who ensure that the product complies with all pertinent laws and regulations. • Manufacturing people who must build the products that contain software. • Sales, marketing, field support, help desk, and • other people who will have to work with the product and its customers

12. Requirements Engineering Process

13. Requirements Engineering Processes • Processes used to discover, analyse and validate system requirements • requirement is "anything that drives design choices" (Lawrence 1997).

14. The IEEE Standard Glossary of Software Engineering Terminology (1990) defines a requirement as • A condition or capability needed by a user to solve a problem or achieve an objective. • A condition or capability that must be met or possessed by a system or system component to satisfy a contract, standard, specification, or other formally imposed document. • A documented representation of a condition or capability as in 1 or 2.

15. The following definition acknowledges the diversity of requirements types (Sommerville and Sawyer 1997): Requirements are...a specification of what should be implemented. They are descriptions of how the system should behave, or of a system property or attribute. They may be a constraint on the development process of the system

16. Software requirements – cont’d • Software requirements include three distinct levels—business requirements, user requirements, and functional requirements. • In addition, every system has an assortment of nonfunctional requirements.

21. Requirements engineering processes • The processes used for RE vary widely depending on the application domain, the people involved and the organisation developing the requirements • However, there are a number of generic activities common to all processes

22. Requirements Engineering Process

24. Elicitation • Sometimes called requirements elicitation or 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 end-users, managers, engineers involved in maintenance, domain experts, trade unions, etc. These are called stakeholders

25. Problems of requirements analysis • Stakeholders don’t know what they really want • Stakeholders express requirements in their own terms • Different stakeholders may have conflicting requirements • Organisational and political factors may influence the system requirements • The requirements change during the analysis process. New stakeholders may emerge and the business environment changes

26. The requirements analysis process Generic model: each organization has its own version

27. Process activities • Domain understanding (how the organization operates) • Requirements collection (interaction with stakeholders) • Classification (into coherent clusters) • Conflict resolution (find & resolve) • Prioritisation (interaction with stakeholders, identification of most important requirements) • Requirements checking (completeness, consistency, real needs) CONTINUOUS FEEDBACK BETWEEN ACTIVITIES

28. Requirements validation • Concerned with demonstrating that the requirements define the system that the customer really wants • Requirements error costs are high so validation is very important • Fixing a requirements error after delivery may cost up to 100 times the cost of fixing an implementation error (it goes through specs, design and implementation)

29. Requirements checking • Validity. Does the system provide the functions which best support the customer’s needs? • Consistency. Are there any requirements conflicts or different descriptions of the same function? • Completeness. Are all functions (and constraints) required by the customer included? • Realism. Can the requirements be implemented given available budget and technology? • Verifiability. Can the requirements be checked? Types of Checks:

30. Requirements validation techniques • Requirements reviews • Systematic manual analysis of the requirements • Prototyping • Using an executable model of the system to check requirements • Test-case generation • Developing tests for requirements to check testability • Tests difficult to implement reveal potential difficulty of implementing requirements • Automated consistency analysis • Checking the consistency of a structured requirements description (formal notation) using a dedicated CASE tool

31. Automated consistency checking

32. Requirements reviews • Regular reviews should be held while the requirements definition is being formulated • Both client and contractor staff should be involved in reviews • Reviews may be formal (with completed documents) or informal. Good communications between developers, customers and users can resolve problems at an early stage

33. Review checks • Verifiability. Is the requirement realistically testable? • Comprehensibility. Is the requirement properly understood by procurers or end-users? • Traceability. Is the origin of the requirement clearly stated? • Adaptability. Can the requirement be changed without a large impact on other requirements?

34. Requirements management • Requirements management is the process of managing changing requirements during the requirements engineering process and system development • Requirements are inevitably incomplete and inconsistent • New requirements emerge during the process as business needs change and a better understanding of the system is developed • Different viewpoints have different requirements and these are often contradictory

35. Requirements change • The priority of requirements from different viewpoints changes during the development process • System customers may specify requirements from a business perspective that conflict with end-user requirements • The business and technical environment of the system changes during its development

36. Requirements evolution

37. Enduring and volatile requirements Evolution perspective : Two classes of requirements • Enduring requirements. Stable requirements derived from the core activity of the customer organisation. E.g. a hospital will always have doctors, nurses, etc. Requirements may be derived from domain models • Volatile requirements. Requirements which change during development or when the system is in use. In a hospital, requirements derived from health-care policy

38. Classification of volatile requirements • Mutable requirements • Requirements that change due to the system’s environment • Emergent requirements • Requirements that emerge as understanding of the system develops • Consequential requirements • Requirements that result from the introduction of the computer system (change of working processes) • Compatibility requirements • Requirements that depend on other systems or organisational processes

39. Requirements management planning • During the requirements engineering process, you have to plan: • Requirements identification • How requirements are individually identified • A change management process • The process followed that assess the cost and impact of changes • Traceability policies • The amount of information about requirements relationships that is maintained • CASE tool support • The tool support required to help manage requirements change

40. Traceability • Traceability is concerned with the relationships between requirements, their sources and the system design • Source traceability • Links from requirements to stakeholders who proposed these requirements • Requirements traceability • Links between dependent requirements to assess how many other requirements will be affected • Design traceability • Links from the requirements to the design modules that implement them

41. A traceability matrix Used to represent traceability information (for a small number of reqs) • A “U” is used when a req. in a row uses the facilities of the req. in the column • An “R” is used when there is a weaker relationship (e.g. reqs are part of the same sub-system)

42. CASE tool support • Requirements storage • Requirements should be managed in a secure, managed data store • Change management • The process of change management is a workflow process whose stages can be defined and information flow between these stages partially automated • Traceability management • Automated retrieval of the links between requirements

43. Requirements change management • Should apply to all proposed changes to the requirements • Principal stages • Problem analysis and change specification. Discuss requirements problem and propose change • Change analysis and costing. Assess effects of change on other requirements • Change implementation. Modify requirements document and other documents to reflect change

44. Requirements change management