Introduction to Software Requirements
description
Transcript of Introduction to Software Requirements
![Page 1: Introduction to Software Requirements](https://reader033.fdocuments.us/reader033/viewer/2022061523/56816703550346895ddb67c8/html5/thumbnails/1.jpg)
Introduction to Software Requirements
Dr Suad AlRamouni
![Page 2: Introduction to Software Requirements](https://reader033.fdocuments.us/reader033/viewer/2022061523/56816703550346895ddb67c8/html5/thumbnails/2.jpg)
◦ 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
Learning Outcomes
![Page 3: Introduction to Software Requirements](https://reader033.fdocuments.us/reader033/viewer/2022061523/56816703550346895ddb67c8/html5/thumbnails/3.jpg)
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
Why Software projects fail?
![Page 4: Introduction to Software Requirements](https://reader033.fdocuments.us/reader033/viewer/2022061523/56816703550346895ddb67c8/html5/thumbnails/4.jpg)
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.
![Page 5: Introduction to Software Requirements](https://reader033.fdocuments.us/reader033/viewer/2022061523/56816703550346895ddb67c8/html5/thumbnails/5.jpg)
Case Study
![Page 6: Introduction to Software Requirements](https://reader033.fdocuments.us/reader033/viewer/2022061523/56816703550346895ddb67c8/html5/thumbnails/6.jpg)
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
Part I. Software Requirements: What, Why, and Who
![Page 7: Introduction to Software Requirements](https://reader033.fdocuments.us/reader033/viewer/2022061523/56816703550346895ddb67c8/html5/thumbnails/7.jpg)
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.
Bad Requirements Costs!
![Page 8: Introduction to Software Requirements](https://reader033.fdocuments.us/reader033/viewer/2022061523/56816703550346895ddb67c8/html5/thumbnails/8.jpg)
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.
![Page 9: Introduction to Software Requirements](https://reader033.fdocuments.us/reader033/viewer/2022061523/56816703550346895ddb67c8/html5/thumbnails/9.jpg)
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.
Stakeholders
![Page 10: Introduction to Software Requirements](https://reader033.fdocuments.us/reader033/viewer/2022061523/56816703550346895ddb67c8/html5/thumbnails/10.jpg)
◦ 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.
![Page 11: Introduction to Software Requirements](https://reader033.fdocuments.us/reader033/viewer/2022061523/56816703550346895ddb67c8/html5/thumbnails/11.jpg)
◦ 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
![Page 12: Introduction to Software Requirements](https://reader033.fdocuments.us/reader033/viewer/2022061523/56816703550346895ddb67c8/html5/thumbnails/12.jpg)
Requirements Engineering Process
![Page 13: Introduction to Software Requirements](https://reader033.fdocuments.us/reader033/viewer/2022061523/56816703550346895ddb67c8/html5/thumbnails/13.jpg)
Processes used to discover, analyse and validate system requirements
requirement is "anything that drives design choices" (Lawrence 1997).
Requirements Engineering Processes
![Page 14: Introduction to Software Requirements](https://reader033.fdocuments.us/reader033/viewer/2022061523/56816703550346895ddb67c8/html5/thumbnails/14.jpg)
The IEEE Standard Glossary of Software Engineering Terminology (1990) defines a requirement as
1. A condition or capability needed by a user to solve a problem or achieve an objective.
2. 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.
3. A documented representation of a condition or capability as in 1 or 2.
![Page 15: Introduction to Software Requirements](https://reader033.fdocuments.us/reader033/viewer/2022061523/56816703550346895ddb67c8/html5/thumbnails/15.jpg)
◦ 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
![Page 16: Introduction to Software Requirements](https://reader033.fdocuments.us/reader033/viewer/2022061523/56816703550346895ddb67c8/html5/thumbnails/16.jpg)
Software requirements include three distinct levels—business requirements, user requirements, and functional requirements.
In addition, every system has an assortment of nonfunctional requirements.
Software requirements – cont’d
![Page 17: Introduction to Software Requirements](https://reader033.fdocuments.us/reader033/viewer/2022061523/56816703550346895ddb67c8/html5/thumbnails/17.jpg)
![Page 18: Introduction to Software Requirements](https://reader033.fdocuments.us/reader033/viewer/2022061523/56816703550346895ddb67c8/html5/thumbnails/18.jpg)
![Page 19: Introduction to Software Requirements](https://reader033.fdocuments.us/reader033/viewer/2022061523/56816703550346895ddb67c8/html5/thumbnails/19.jpg)
![Page 20: Introduction to Software Requirements](https://reader033.fdocuments.us/reader033/viewer/2022061523/56816703550346895ddb67c8/html5/thumbnails/20.jpg)
![Page 21: Introduction to Software Requirements](https://reader033.fdocuments.us/reader033/viewer/2022061523/56816703550346895ddb67c8/html5/thumbnails/21.jpg)
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
Requirements engineering processes
![Page 22: Introduction to Software Requirements](https://reader033.fdocuments.us/reader033/viewer/2022061523/56816703550346895ddb67c8/html5/thumbnails/22.jpg)
Requirements Elicitation
Requirements Analysis
Requirements
Specification
Requirements Validation
Requirements
Management
Requirements Engineering Process
![Page 23: Introduction to Software Requirements](https://reader033.fdocuments.us/reader033/viewer/2022061523/56816703550346895ddb67c8/html5/thumbnails/23.jpg)
Requirements Engineering
Requirements Development
s
Elicitations Analysis Specification Validation
Requirements Management
![Page 24: Introduction to Software Requirements](https://reader033.fdocuments.us/reader033/viewer/2022061523/56816703550346895ddb67c8/html5/thumbnails/24.jpg)
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
Elicitation
![Page 25: Introduction to Software Requirements](https://reader033.fdocuments.us/reader033/viewer/2022061523/56816703550346895ddb67c8/html5/thumbnails/25.jpg)
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
Problems of requirements analysis
![Page 26: Introduction to Software Requirements](https://reader033.fdocuments.us/reader033/viewer/2022061523/56816703550346895ddb67c8/html5/thumbnails/26.jpg)
The requirements analysis process
Requirementsvalidation
Domainunderstanding Prioritization
Requirementscollection
Conflictresolution
Classification
Requirementsdefinition andspecification
Processentry
Generic model: each organization has its own version
![Page 27: Introduction to Software Requirements](https://reader033.fdocuments.us/reader033/viewer/2022061523/56816703550346895ddb67c8/html5/thumbnails/27.jpg)
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)
Process activities
CONTINUOUS FEEDBACK BETWEEN ACTIVITIES
![Page 28: Introduction to Software Requirements](https://reader033.fdocuments.us/reader033/viewer/2022061523/56816703550346895ddb67c8/html5/thumbnails/28.jpg)
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)
Requirements validation
![Page 29: Introduction to Software Requirements](https://reader033.fdocuments.us/reader033/viewer/2022061523/56816703550346895ddb67c8/html5/thumbnails/29.jpg)
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?
Requirements checkingTypes of Checks:
![Page 30: Introduction to Software Requirements](https://reader033.fdocuments.us/reader033/viewer/2022061523/56816703550346895ddb67c8/html5/thumbnails/30.jpg)
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
Requirements validation techniques
![Page 31: Introduction to Software Requirements](https://reader033.fdocuments.us/reader033/viewer/2022061523/56816703550346895ddb67c8/html5/thumbnails/31.jpg)
Automated consistency checking
Requirementsdatabase
Requirementsanalyser
Requirementsproblem report
Requirementsprocessor
Requirementsin a formal language
![Page 32: Introduction to Software Requirements](https://reader033.fdocuments.us/reader033/viewer/2022061523/56816703550346895ddb67c8/html5/thumbnails/32.jpg)
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
Requirements reviews
![Page 33: Introduction to Software Requirements](https://reader033.fdocuments.us/reader033/viewer/2022061523/56816703550346895ddb67c8/html5/thumbnails/33.jpg)
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?
Review checks
![Page 34: Introduction to Software Requirements](https://reader033.fdocuments.us/reader033/viewer/2022061523/56816703550346895ddb67c8/html5/thumbnails/34.jpg)
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
Requirements management
![Page 35: Introduction to Software Requirements](https://reader033.fdocuments.us/reader033/viewer/2022061523/56816703550346895ddb67c8/html5/thumbnails/35.jpg)
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
Requirements change
![Page 36: Introduction to Software Requirements](https://reader033.fdocuments.us/reader033/viewer/2022061523/56816703550346895ddb67c8/html5/thumbnails/36.jpg)
Requirements evolution
Changedunderstanding
of problem
Initialunderstanding
of problem
Changedrequirements
Initialrequirements
Time
![Page 37: Introduction to Software Requirements](https://reader033.fdocuments.us/reader033/viewer/2022061523/56816703550346895ddb67c8/html5/thumbnails/37.jpg)
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
Enduring and volatile requirements
Evolution perspective : Two classes of requirements
![Page 38: Introduction to Software Requirements](https://reader033.fdocuments.us/reader033/viewer/2022061523/56816703550346895ddb67c8/html5/thumbnails/38.jpg)
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
Classification of volatile requirements
![Page 39: Introduction to Software Requirements](https://reader033.fdocuments.us/reader033/viewer/2022061523/56816703550346895ddb67c8/html5/thumbnails/39.jpg)
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
Requirements management planning
![Page 40: Introduction to Software Requirements](https://reader033.fdocuments.us/reader033/viewer/2022061523/56816703550346895ddb67c8/html5/thumbnails/40.jpg)
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
Traceability
![Page 41: Introduction to Software Requirements](https://reader033.fdocuments.us/reader033/viewer/2022061523/56816703550346895ddb67c8/html5/thumbnails/41.jpg)
A traceability matrix
Req.id
1.1 1.2 1.3 2.1 2.2 2.3 3.1 3.2
1.1 U R1.2 U R U1.3 R R2.1 R U U2.2 U2.3 R U3.1 R3.2 R
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)
![Page 42: Introduction to Software Requirements](https://reader033.fdocuments.us/reader033/viewer/2022061523/56816703550346895ddb67c8/html5/thumbnails/42.jpg)
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
CASE tool support
![Page 43: Introduction to Software Requirements](https://reader033.fdocuments.us/reader033/viewer/2022061523/56816703550346895ddb67c8/html5/thumbnails/43.jpg)
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
Requirements change management
![Page 44: Introduction to Software Requirements](https://reader033.fdocuments.us/reader033/viewer/2022061523/56816703550346895ddb67c8/html5/thumbnails/44.jpg)
Requirements change management
Changeimplementation
Change analysisand costing
Problem analysis andchange specification
Identifiedproblem
Revisedrequirements