chapter 6+7 in textbook 1 chapter 4 software requirements 1
TRANSCRIPT
Chapter 6+7 in textbook
1
Chapter 4Software Requirements
1
2
Please join Tawasol
Group number : 92705
Objectives
3
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) Understand the requirements engineering
processUnderstand how to discover requirementsUnderstand how to validate requirementsUnderstand how to manage requirements
3
Overview
4
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 The requirements engineering process. Feasibility study Requirements elicitation Requirements specification Requirements validation Requirements management
4
What are Software Requirements
5
“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.
The LIBSYS case study
6
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.
Requirements types
7
1. Functional requirementsStatements of services the system should provide,
how the system should react to particular inputs and how the system should behave in particular situations.
2. Non-functional requirementsconstraints on the services or functions offered by the
system such as timing constraints, constraints on the development process, standards, etc.
3. Domain requirementsRequirements that come from the application domain
of the system and that reflect characteristics of that domain.
Functional Requirements
8
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 are high-level statements
of what the system should System requirements should describe the
system services in detail.
Examples
9
1. The user shall be able to search either all of the initial set of databases or select a subset from it.
2. The system shall provide appropriate viewers for the user to read documents in the document store.
3. Every order shall be allocated a unique identifier (ORDER_ID) which the user shall be able to copy to the account’s permanent storage area.
Problems
10
Problems arise when requirements are not precisely stated (Ambiguous)
Ambiguous requirements may be interpreted in different ways
by developers and users.
Consider the term ‘appropriate viewers’User intention - special purpose viewer for each
different document type;Developer interpretation - Provide a text viewer
that shows the contents of the document.
Non-Functional Requirements
11
These define system properties, constraints,
and process requirements
System Properties
12
Reliability,Response time Maintainability Storage requirements.
Constraints
13
I/O device capability, Data representations
Process Requirements
14
Mandating a particular CASE system, Programming language or Development method.
15
Which do you think is more critical ,
A functional or non-functional requirement and why?
Have a look at the following video
Europeana Project
16
Non-functional classifications
17
Product requirementsRequirements which specify that the delivered product
must behave in a particular way e.g. execution speed, reliability, etc.
Organisational requirementsRequirements which are a consequence of
organisational policies and procedures e.g. process standards used, implementation requirements, etc.
External requirementsRequirements which arise from factors which are
external to the system and its development process e.g. interoperability requirements, legislative requirements, etc.
Types of Non-functional requirements
18
Performancerequirements
Spacerequirements
Usabilityrequirements
Efficiencyrequirements
Reliabilityrequirements
Portabilityrequirements
Interoperabilityrequirements
Ethicalrequirements
Legislativerequirements
Implementationrequirements
Standardsrequirements
Deliveryrequirements
Safetyrequirements
Privacyrequirements
Productrequirements
Organisationalrequirements
Externalrequirements
Non-functionalrequirements
Examples
19
Product requirement The user interface for LIBSYS shall be
implemented as simple HTML without frames or Java applets.
Organisational requirementThe system development process and deliverable documents shall conform to the process and deliverables defined in XYZCo-SP-STAN-95.
External requirementThe system shall not disclose any personal information about customers apart from their name and reference number to the operators of the system.
Verifiable Non-functional requirements
20
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.
Example
21
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.
Requirements measures
22
Property Measure
Speed Processed transactions/secondUser/Event response timeScreen refresh time
Size M BytesNumber of ROM chips
Ease of use Training timeNumber of help frames
Reliability Mean time to failureProbability of unavailabilityRate of failure occurrenceAvailability
Robustness Time to restart after failurePercentage of events causing failureProbability of data corruption on failure
Portability Percentage of target dependent statementsNumber of target systems
Domain Requirements
23
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.
Library system domain requirements
There shall be a standard user interface to all databases which shall be based on the Z39.50 standard (library standard -design constraint ).
Because of copyright restrictions, some documents must be deleted immediately on arrival. Depending on the user’s requirements, these documents will either be printed locally on the system server for manually forwarding to the user or routed to a network printer.
Train protection system
The deceleration of the train shall be computed as:Dtrain = Dcontrol + Dgradient
where Dgradient is 9.81ms2 * compensated gradient/alpha and where the values of 9.81ms2 /alpha are known for different types of train.
Class Activity
26
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 0.5 (out of 2
in-class marks)
User Requirements
27
Written for customersStatements in natural languageDescribe the services the system
provides and its operational constraints.May include diagrams or tablesShould 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.
System Requirements
28
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.
Guidelines for writing requirements
29
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.
Definition and Specifications
30
1. The software must provide a means of representing and1. accessing external files created by other tools.
1.1 The user should be provided with facilities to define the type of1.2 external files.1.2 Each external file type may have an associated tool which may be1.2 applied to the file.1.3 Each external file type may be represented as a specific icon on1.2 the user’s display.1.4 Facilities should be provided for the icon representing an1.2 external file type to be defined by the user.1.5 When a user selects an icon representing an external file, the1.2 effect of that selection is to apply the tool associated with the type of1.2 the external file to the file represented by the selected icon.
User requirement definition
System requirements specification
Interface Specification
31
Most systems must operate with other systems and the operating interfaces must be specified as part of the requirements.
Why is it important to get it right?
32
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.
33
Representing Requirements The SRS document
34
The Software Requirements Specification (SRS)
document is the official statement of what is
required of the system developers.
The SRS document
35
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.
Users of the SRS
36
Use the requirements todevelop validation tests for
the system
Use the requirementsdocument to plan a bid forthe system and to plan the
system development process
Use the requirements tounderstand what system is to
be developed
System testengineers
Managers
Systemengineers
Specify the requirements andread them to check that they
meet their needs. Theyspecify changes to the
requirements
Systemcustomers
Use the requirements to helpunderstand the system and
the relationships between itsparts
Systemmaintenanceengineers
Structure of the SRS
37
PrefaceIntroductionGlossaryUser requirements definitionSystem architecture (high level)System requirements specificationSystem modelsSystem evolutionAppendicesIndex
Requirements Engineering Process
38
“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.
Requirements engineering
39
Involves the following processesFeasibility Study Feasibility Report
Requirements elicitation System Models
Requirements Specification user and system requirements
Requirements validation Requirements document (SRS)
+ Requirements Management
Requirements Engineering Process
40
Feasibilitystudy
Requirementselicitation and
analysisRequirementsspecification
Requirementsvalidation
Feasibilityreport
Systemmodels
User and systemrequirements
Requirementsdocument
The Feasibility Study
41
A feasibility study decides whether or not the proposed system is worthwhile.
A short focused study that checksIf 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.
Requirements Elicitation
42
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.
“refer to any person or group who will be affected by the system, directly or in directly.”
Requirements discovery
43
Sources of informationDocumentationSystem stakeholders
Interviews (close, open)Understand and critique real-life examples. (scenarios , prototypes)
Observation (ethnography)Specifications of similar systems
Stakeholders for LIBSYS
44
Can you identify possible stakeholders for the LIBSYS?
Library managerArticle providersStudentsStaff (library , finance, maintenance etc..)
45
Articleproviders
FinanceLibrarymanager
Librarystaff
Users
InteractorIndirect
All VPs
Classificationsystem
UIstandards
Domain
ExternalStaffStudents CataloguersSystem
managers
Analysis : System models
46
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.
Requirements specification
47
It is the final work product produced by the requirements engineer.
The SRS documentIt serves as a foundation for the software design and implementation.
Requirements Validation
48
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.
Validation checks
49
Validity checks◦ Is this what the user wants?◦ Does the system provide the functions which best support
the customer’s needs?Consistency checks
◦ Requirements should not conflictCompleteness checks
◦ Requirements should define all functions and constraints◦ Are all functions required by the customer included?
Realism checks◦ Ensure they could be implemented ◦ Can the requirements be implemented given available
budget and technologyVerifiability
◦ Requirements should be written so that they are verifiable, you should be able to write tests for each requirement.
Validation techniques
50
Requirements reviewsA team of reviewers manually check the
requirements. Prototyping
An executable model of the system is demonstrated to customers.
Test-case generationRequirements should be testable. If tests are
difficult or impossible to design, this means that the requirements will be difficult to implement.
Developing tests before any code is written is used in ----?
Requirements Management
51
Why?Requirements for large software systems are
always changing. Because the problem can not be fully specified, the requirements are usually incomplete and bound to change.
During the software process the stakeholders understanding of the problem is constantly changing
After the system is installed, new requirements will emerge.
What? It is the process of understanding and
controlling changes to system requirements.
Requirements Management Planning
52
Requirements identificationEach requirement must be uniquely
identifiedA change management process
Assess the impact and cost of changeTraceability policies
Define the relationship between requirements
CASE tool support
Class Activity
53
Working with your team, list the most important characteristics of good requirements.
When you are done discuss your decisions with the rest of the class.
Check each characteristic, if you got it right give yourself 1 point.
Compute your total. The winning teams will get a 0.5 (out of 2
in-class marks)
Good RequirementsCharacteristic Explanation
Complete Everything the software is supposed to do and responses of the software to all classes of input data are specified in the SRS
Consistent The requirement does not contradict any other requirement
Correct Every requirement in the SRS represents something required in the final system.
Unambiguous The requirement is concisely stated without recourse to technical jargon, acronyms (unless defined elsewhere in the Requirements document). Every requirement has one and only one interpretation.
Verifiable There is a cost effective method that can check whether the final software meets the requirement.