1 Software Requirements Descriptions and specifications of a system Descriptions and specifications...
-
Upload
avis-gilbert -
Category
Documents
-
view
235 -
download
0
Transcript of 1 Software Requirements Descriptions and specifications of a system Descriptions and specifications...
11
Software RequirementsSoftware Requirements
Descriptions and Descriptions and specifications of a specifications of a system system
22
ObjectivesObjectives To introduce the concepts of user and To introduce the concepts of user and
system requirementssystem requirements To describe functional and non-To describe functional and non-
functional requirementsfunctional requirements To explain two techniques for To explain two techniques for
describing system requirementsdescribing system requirements To explain how software requirements To explain how software requirements
may be organised in a requirements may be organised in a requirements documentdocument
33
Topics coveredTopics covered Functional and non-functional Functional and non-functional
requirementsrequirements User requirementsUser requirements System requirementsSystem requirements The software requirements documentThe software requirements document
44
Requirements engineeringRequirements engineering The process of establishing the services The process of establishing the services
that the customer requires from a that the customer requires from a system and the constraints under system and the constraints under which it operates and is developedwhich it operates and is developed
The requirements themselves are the The requirements themselves are the descriptions of the system services and descriptions of the system services and constraints that are generated during constraints that are generated during the requirements engineering processthe requirements engineering process
55
What is a requirement?What is a requirement? It may range from a high-level abstract It may range from a high-level abstract
statement of a service or of a system constraint statement of a service or of a system constraint to a detailed mathematical functional to a detailed mathematical functional specificationspecification
This is inevitable as requirements may serve a This is inevitable as requirements may serve a dual functiondual function• May be the basis for a bid for a contract - therefore May be the basis for a bid for a contract - therefore
must be open to interpretationmust be open to interpretation• May be the basis for the contract itself - therefore May be the basis for the contract itself - therefore
must be defined in detailmust be defined in detail• Both these statements may be called requirementsBoth these statements may be called requirements
66
Types of requirementTypes of requirement User requirementsUser requirements
• Statements in natural language plus Statements in natural language plus diagrams of the services the system diagrams of the services the system provides and its operational constraints. provides and its operational constraints. Written for customersWritten for customers
System requirementsSystem requirements• A structured document setting out detailed A structured document setting out detailed
descriptions of the system services. Written descriptions of the system services. Written as a contract between client and contractoras a contract between client and contractor
Software specificationSoftware specification• A detailed software description which can A detailed software description which can
serve as a basis for a design or serve as a basis for a design or implementation. Written for developersimplementation. Written for developers
77
Definitions and specificationsDefinitions and specifications
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.
Requirements definition
Requirements specification
88
Requirements readersRequirements readersClient managersSystem end-usersClient engineersContractor managersSystem architects
System end-usersClient engineersSystem architectsSoftware developers
Client engineers (perhaps)System architectsSoftware developers
User requirements
System requirements
Software designspecification
99
Functional and non-functional requirementsFunctional and non-functional requirements
Functional requirementsFunctional requirements• Statements of services the system should provide, how Statements of services the system should provide, how
the system should react to particular inputs and how the the system should react to particular inputs and how the system should behave in particular situations.system should behave in particular situations.
Non-functional requirementsNon-functional requirements• constraints on the services or functions offered by the constraints on the services or functions offered by the
system such as timing constraints, constraints on the system such as timing constraints, constraints on the development process, standards, etc.development process, standards, etc.
Domain requirementsDomain requirements• Requirements that come from the application domain of Requirements that come from the application domain of
the system and that reflect characteristics of that domainthe system and that reflect characteristics of that domain
1010
Functional requirementsFunctional requirements Describe functionality or system servicesDescribe functionality or system services Depend on the type of software, Depend on the type of software,
expected users and the type of system expected users and the type of system where the software is usedwhere the software is used
Functional user requirements may be Functional user requirements may be high-level statements of what the system high-level statements of what the system should do but functional system should do but functional system requirements should describe the system requirements should describe the system services in detailservices in detail
1111
Examples of functional requirementsExamples of functional requirements
The user shall be able to search either all of The user shall be able to search either all of the initial set of databases or select a the initial set of databases or select a subset from it.subset from it.
The system shall provide appropriate The system shall provide appropriate viewers for the user to read documents in viewers for the user to read documents in the document store. the document store.
Every order shall be allocated a unique Every order shall be allocated a unique identifier (ORDER_ID) which the user shall identifier (ORDER_ID) which the user shall be able to copy to the account’s permanent be able to copy to the account’s permanent storage area.storage area.
1212
Requirements imprecisionRequirements imprecision Problems arise when requirements are not Problems arise when requirements are not
precisely statedprecisely stated Ambiguous requirements may be Ambiguous requirements may be
interpreted in different ways by developers interpreted in different ways by developers and usersand users
Consider the term ‘appropriate viewers’Consider the term ‘appropriate viewers’• User intention - special purpose viewer for each User intention - special purpose viewer for each
different document typedifferent document type• Developer interpretation - Provide a text viewer Developer interpretation - Provide a text viewer
that shows the contents of the documentthat shows the contents of the document
1313
Requirements completeness and Requirements completeness and consistencyconsistency
In principle requirements should be both complete In principle requirements should be both complete
and consistentand consistent CompleteComplete
• They should include descriptions of all facilities requiredThey should include descriptions of all facilities required
ConsistentConsistent• There should be no conflicts or contradictions in the There should be no conflicts or contradictions in the
descriptions of the system facilitiesdescriptions of the system facilities
In practice, it is impossible to produce a complete In practice, it is impossible to produce a complete
and consistent requirements documentand consistent requirements document
1414
Non-functional requirementsNon-functional requirements
Define system properties and constraints e.g. Define system properties and constraints e.g. reliability, response time and storage reliability, response time and storage requirements. Constraints are I/O device requirements. Constraints are I/O device capability, system representations, etc.capability, system representations, etc.
Process requirements may also be specified Process requirements may also be specified mandating a particular CASE system, mandating a particular CASE system, programming language or development methodprogramming language or development method
Non-functional requirements may be more Non-functional requirements may be more critical than functional requirements. If these are critical than functional requirements. If these are not met, the system is uselessnot met, the system is useless
1515
Non-functional classificationsNon-functional classifications Product requirementsProduct requirements
• Requirements which specify that the delivered product Requirements which specify that the delivered product must behave in a particular way e.g. execution speed, must behave in a particular way e.g. execution speed, reliability, etc.reliability, etc.
Organisational requirementsOrganisational requirements• Requirements which are a consequence of organisational Requirements which are a consequence of organisational
policies and procedures e.g. process standards used, policies and procedures e.g. process standards used, implementation requirements, etc.implementation requirements, etc.
External requirementsExternal requirements• Requirements which arise from factors which are external Requirements which arise from factors which are external
to the system and its development process e.g. to the system and its development process e.g. interoperability requirements, legislative requirements, etc.interoperability requirements, legislative requirements, etc.
1616
Non-functional requirement typesNon-functional requirement types
Performancerequirements
Spacerequirements
Usabilityrequirements
Efficiencyrequirements
Reliabilityrequirements
Portabilityrequirements
Interoperabilityrequirements
Ethicalrequirements
Legislativerequirements
Implementationrequirements
Standardsrequirements
Deliveryrequirements
Safetyrequirements
Privacyrequirements
Productrequirements
Organizationalrequirements
Externalrequirements
Non-functionalrequirements
1717
Non-functional requirements examplesNon-functional requirements examples Product requirementProduct requirement
• 4.C.8 It shall be possible for all necessary communication 4.C.8 It shall be possible for all necessary communication between the APSE and the user to be expressed in the between the APSE and the user to be expressed in the standard Ada character setstandard Ada character set
Organisational requirementOrganisational requirement• 9.3.2 The system development process and deliverable 9.3.2 The system development process and deliverable
documents shall conform to the process and deliverables documents shall conform to the process and deliverables defined in XYZCo-SP-STAN-95defined in XYZCo-SP-STAN-95
External requirementExternal requirement• 7.6.5 The system shall not disclose any personal 7.6.5 The system shall not disclose any personal
information about customers apart from their name and information about customers apart from their name and reference number to the operators of the systemreference number to the operators of the system
1818
Goals and requirementsGoals and requirements Non-functional requirements may be very Non-functional requirements may be very
difficult to state precisely and imprecise difficult to state precisely and imprecise requirements may be difficult to verify. requirements may be difficult to verify.
GoalGoal• A general intention of the user such as ease of useA general intention of the user such as ease of use
Verifiable non-functional requirementVerifiable non-functional requirement• A statement using some measure that can be A statement using some measure that can be
objectively testedobjectively tested
Goals are helpful to developers as they convey Goals are helpful to developers as they convey the intentions of the system usersthe intentions of the system users
1919
ExamplesExamples
A system goalA system goal
• The system should be easy to use by experienced The system should be easy to use by experienced
controllers and should be organised in such a way that controllers and should be organised in such a way that
user errors are minimised.user errors are minimised.
A verifiable non-functional requirementA verifiable non-functional requirement
• Experienced controllers shall be able to use all the Experienced controllers shall be able to use all the
system functions after a total of two hours training. system functions after a total of two hours training.
After this training, the average number of errors made After this training, the average number of errors made
by experienced users shall not exceed two per day.by experienced users shall not exceed two per day.
2020
Requirements measuresRequirements measuresProperty MeasureSpeed Processed transactions/second
User/Event response timeScreen refresh time
Size K BytesNumber of RAM 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
2121
Requirements interactionRequirements interaction Conflicts between different non-functional Conflicts between different non-functional
requirements are common in complex requirements are common in complex systemssystems
Spacecraft systemSpacecraft system• To minimise weight, the number of separate chips To minimise weight, the number of separate chips
in the system should be minimisedin the system should be minimised• To minimise power consumption, lower power To minimise power consumption, lower power
chips should be usedchips should be used• However, using low power chips may mean that However, using low power chips may mean that
more chips have to be used. Which is the most more chips have to be used. Which is the most critical requirement?critical requirement?
2222
Domain requirementsDomain requirements
Derived from the application domain Derived from the application domain and describe system characteristics and describe system characteristics and features that reflect the domainand features that reflect the domain
May be new functional requirements, May be new functional requirements, constraints on existing requirements constraints on existing requirements or define specific computationsor define specific computations
If domain requirements are not If domain requirements are not satisfied, the system may be satisfied, the system may be unworkableunworkable
2323
Library system domain Library system domain requirementsrequirements
There shall be a standard user interface to There shall be a standard user interface to all databases which shall be based on the all databases which shall be based on the Z39.50 standard.Z39.50 standard.
Because of copyright restrictions, some Because of copyright restrictions, some documents must be deleted immediately documents must be deleted immediately on arrival. Depending on the user’s on arrival. Depending on the user’s requirements, these documents will either requirements, these documents will either be printed locally on the system server for be printed locally on the system server for manually forwarding to the user or routed manually forwarding to the user or routed to a network printer.to a network printer.
2424
Domain requirements problemsDomain requirements problems
UnderstandabilityUnderstandability• Requirements are expressed in the Requirements are expressed in the
language of the application domainlanguage of the application domain• This is often not understood by software This is often not understood by software
engineers developing the systemengineers developing the system ImplicitnessImplicitness
• Domain specialists understand the area Domain specialists understand the area so well that they do not think of making so well that they do not think of making the domain requirements explicitthe domain requirements explicit
2525
User requirementsUser requirements
Should describe functional and non-Should describe functional and non-functional requirements so that they functional requirements so that they are understandable by system users are understandable by system users who don’t have detailed technical who don’t have detailed technical knowledgeknowledge
User requirements are defined using User requirements are defined using natural language, tables and natural language, tables and diagramsdiagrams
2626
Problems with natural languageProblems with natural language
Lack of clarity Lack of clarity • Precision is difficult without making the Precision is difficult without making the
document difficult to readdocument difficult to read Requirements confusionRequirements confusion
• Functional and non-functional Functional and non-functional requirements tend to be mixed-uprequirements tend to be mixed-up
Requirements amalgamationRequirements amalgamation• Several different requirements may be Several different requirements may be
expressed togetherexpressed together
2727
Database requirementDatabase requirement
4.A.5 The database shall support the generation and control of configuration objects; that is, objects which are themselves groupings of other objects in the database. The configuration control facilities shall allow access to the objects in a version group by the use of an incomplete name.
2828
Editor grid requirementEditor grid requirement
2.6 Grid facilities To assist in the positioning of entities on a diagram, the user may turn on a grid in either centimetres or inches, via an option on the control panel. Initially, the grid is off. The grid may be turned on and off at any time during an editing session and can be toggled between inches and centimetres at any time. A grid option will be provided on the reduce-to-fit view but the number of grid lines shown will be reduced to avoid filling the smaller diagram with grid lines.
2929
Requirement problemsRequirement problems Database requirements includes both Database requirements includes both
conceptual and detailed informationconceptual and detailed information• Describes the concept of configuration control Describes the concept of configuration control
facilitiesfacilities• Includes the detail that objects may be accessed Includes the detail that objects may be accessed
using an incomplete nameusing an incomplete name Grid requirement mixes three different kinds of Grid requirement mixes three different kinds of
requirementrequirement• Conceptual functional requirement (the need for a Conceptual functional requirement (the need for a
grid)grid)• Non-functional requirement (grid units)Non-functional requirement (grid units)• Non-functional UI requirement (grid switching)Non-functional UI requirement (grid switching)
3030
Guidelines for writing Guidelines for writing requirementsrequirements
Invent a standard format and use it for Invent a standard format and use it for all requirementsall requirements
Use language in a consistent way. Use Use language in a consistent way. Use shall for mandatory requirements, shall for mandatory requirements, should for desirable requirementsshould for desirable requirements
Use text highlighting to identify key Use text highlighting to identify key parts of the requirementparts of the requirement
Avoid the use of computer jargonAvoid the use of computer jargon
3131
System requirementsSystem requirements
More detailed specifications of user More detailed specifications of user requirementsrequirements
Serve as a basis for designing the Serve as a basis for designing the systemsystem
May be used as part of the system May be used as part of the system contractcontract
System requirements may be System requirements may be expressed using system modelsexpressed using system models
3232
Requirements and designRequirements and design
In principle, requirements should state what In principle, requirements should state what the system should do and the design should the system should do and the design should describe how it does thisdescribe how it does this
In practice, requirements and design are In practice, requirements and design are inseparableinseparable• A system architecture may be designed to A system architecture may be designed to
structure the requirementsstructure the requirements• The system may inter-operate with other The system may inter-operate with other
systems that generate design requirementssystems that generate design requirements• The use of a specific design may be a domain The use of a specific design may be a domain
requirementrequirement
3333
Structured language Structured language specificationsspecifications
A limited form of natural language A limited form of natural language may be used to express may be used to express requirementsrequirements
This removes some of the problems This removes some of the problems resulting from ambiguity and resulting from ambiguity and flexibility and imposes a degree of flexibility and imposes a degree of uniformity on a specificationuniformity on a specification
Often bast supported using a forms-Often bast supported using a forms-based approachbased approach
3434
Form-based specificationsForm-based specifications Definition of the function or entityDefinition of the function or entity Description of inputs and where they Description of inputs and where they
come fromcome from Description of outputs and where they Description of outputs and where they
go togo to Indication of other entities requiredIndication of other entities required Pre and post conditions (if appropriate)Pre and post conditions (if appropriate) The side effects (if any)The side effects (if any)
3535
PDL-based requirements definitionPDL-based requirements definition Requirements may be defined operationally using a Requirements may be defined operationally using a
language like a programming language but with language like a programming language but with more flexibility of expressionmore flexibility of expression
Most appropriate in two situationsMost appropriate in two situations• Where an operation is specified as a sequence of actions Where an operation is specified as a sequence of actions
and the order is importantand the order is important• When hardware and software interfaces have to be When hardware and software interfaces have to be
specifiedspecified Disadvantages areDisadvantages are
• The PDL may not be sufficiently expressive to define The PDL may not be sufficiently expressive to define domain conceptsdomain concepts
• The specification will be taken as a design rather than a The specification will be taken as a design rather than a specificationspecification
3636
PDL disadvantagesPDL disadvantages
PDL may not be sufficiently expressive PDL may not be sufficiently expressive to express the system functionality in to express the system functionality in an understandable wayan understandable way
Notation is only understandable to Notation is only understandable to people with programming language people with programming language knowledgeknowledge
The requirement may be taken as a The requirement may be taken as a design specification rather than a design specification rather than a model to help understand the systemmodel to help understand the system
3737
Interface specificationInterface specification Most systems must operate with other Most systems must operate with other
systems and the operating interfaces must systems and the operating interfaces must be specified as part of the requirementsbe specified as part of the requirements
Three types of interface may have to be Three types of interface may have to be defineddefined• Procedural interfacesProcedural interfaces• Data structures that are exchangedData structures that are exchanged• Data representationsData representations
Formal notations are an effective technique Formal notations are an effective technique for interface specificationfor interface specification
3838
The requirements documentThe requirements document The requirements document is the The requirements document is the
official statement of what is required official statement of what is required of the system developersof the system developers
Should include both a definition and Should include both a definition and a specification of requirementsa specification of requirements
It is NOT a design document. As far It is NOT a design document. As far as possible, it should set of WHAT the as possible, it should set of WHAT the system should do rather than HOW it system should do rather than HOW it should do itshould do it
3939
Users of a Users of a requirements requirements
documentdocument
Use the requirements todevelop validation tests forthe system
Use the requirementsdocument to plan a bid forthe system and to plan thesystem development process
Use the requirements tounderstand what system is tobe developed
System testengineers
Managers
System engineers
Specify the requirements andread them to check that theymeet their needs. Theyspecify changes to therequirements
System customers
Use the requirements to helpunderstand the system andthe relationships between itsparts
Systemmaintenance
engineers
4040
Requirements document requirementsRequirements document requirements
Specify external system behaviourSpecify external system behaviour Specify implementation constraintsSpecify implementation constraints Easy to changeEasy to change Serve as reference tool for maintenanceServe as reference tool for maintenance Record forethought about the life cycle Record forethought about the life cycle
of the system i.e. predict changesof the system i.e. predict changes Characterise responses to unexpected Characterise responses to unexpected
eventsevents
4141
IEEE requirements standardIEEE requirements standard IntroductionIntroduction General descriptionGeneral description Specific requirementsSpecific requirements AppendicesAppendices IndexIndex This is a generic structure that must This is a generic structure that must
be instantiated for specific systemsbe instantiated for specific systems
4242
Requirements document structureRequirements document structure
IntroductionIntroduction GlossaryGlossary User requirements definitionUser requirements definition System architectureSystem architecture System requirements specificationSystem requirements specification System modelsSystem models System evolutionSystem evolution AppendicesAppendices IndexIndex
4343
Key pointsKey points Requirements set out what the system should do Requirements set out what the system should do
and define constraints on its operation and and define constraints on its operation and
implementationimplementation Functional requirements set out services the Functional requirements set out services the
system should providesystem should provide Non-functional requirements constrain the system Non-functional requirements constrain the system
being developed or the development processbeing developed or the development process User requirements are high-level statements of User requirements are high-level statements of
what the system should dowhat the system should do
4444
Key pointsKey points
User requirements should be written in natural User requirements should be written in natural language, tables and diagramslanguage, tables and diagrams
System requirements are intended to System requirements are intended to communicate the functions that the system communicate the functions that the system should provideshould provide
System requirements may be written in System requirements may be written in structured natural language, a PDL or in a structured natural language, a PDL or in a formal languageformal language
A software requirements document is an A software requirements document is an agreed statement of the system requirementsagreed statement of the system requirements