Presentation on theme: "Overview of Software Requirements"— Presentation transcript:
1 Overview of Software Requirements Descriptions and specifications of a system and the process whereby they are derivedObjectivesTo introduce the concepts of user and system requirementsTo describe functional and non-functional requirementsTo describe the principal requirements engineering activitiesTo introduce techniques for requirements elicitation and analysis
2 Requirements engineering The process of establishing the services that the customer requires from a system and the constraints under which it operates and is developedThe requirements themselves are the descriptions of the system services and constraints that are generated during the requirements engineering processRequirements specify what the system is supposed to do, but not how the system is to accomplish its task
3 What is a requirement? It may span a wide range of statements from a high-level abstract statement of a service or of a system constraintto a detailed mathematical functional specificationTypes of requirementsUser requirementsSystem requirementsSoftware specifications – provide more (design) detail
4 User requirementsShould describe functional and non-functional requirements so that they are understandable by system users who don’t have detailed technical knowledgeUser requirements are defined using natural language, tables, and diagramsProblems with natural languagePrecision vs. understandabilityFunctional vs. non-functional requirements confusionRequirements amalgamation
5 System requirements More detailed specifications of user requirements Serve as a basis for designing the systemMay be used as part of the system contractSystem requirements may be expressed using system models discussed on January 30
6 Definitions and specifications 1.Thesoftwarmupvidngcxlbyfile,th1.2coasnpydwxrbRqumonciltesodfnhyp1.2xraEmvwb3ciconon1.2theuser’sdisplay.1.4Facilitiesshouldbeprovidedfortheiconrepresentingan1.2externalfiletypetobedefinedbytheuser.1.5Whenauserselectsaniconrepresentinganexternal
7 Functional and non-functional requirements Statements of services the system should provide, how the system should react to particular inputs and how the system should behave in particular situations.Non-functional requirementsconstraints on the services or functions offered by the system such as timing constraints, constraints on the development process, standards, etc.Domain requirementsRequirements that come from the application domain of the system and that reflect characteristics of that domain
8 Examples of functional requirements The user shall be able to search either all of the initial set of databases or select a subset from it.The system shall provide appropriate viewers for the user to read documents in the document store.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.
9 Requirements precision, completeness, and consistency In principle requirements should be precise, complete, and consistentPreciseThey should state exactly what is desired of the systemCompleteThey should include descriptions of all facilities requiredConsistentThere should be no conflicts or contradictions in the descriptions of the system facilitiesIn practice, it is very difficult to produce a complete and consistent requirements document
10 Ambiguous/imprecise requirement 4.A.5 The database shall only 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.What about non-configuration objects?What about other database functionality?What about level of service other than support?Something else?
12 Non-functional requirements examples Product requirement4.C.8 It shall be possible for all necessary communication between the APSE and the user to be expressed in the standard Ada character setOrganisational requirementThe system development process and deliverable documents shall conform to the process and deliverables defined in XYZCo-SP-STAN-95External requirementThe system shall not disclose any personal information about customers apart from their name and reference number to the operators of the system
14 Requirements interaction Conflicts between different non-functional requirements are common in complex systemsSpacecraft systemTo minimise weight, the number of separate chips in the system should be minimisedTo minimise power consumption, lower power chips should be usedBut, using low power chips may mean that more chips have to be usedWhich is the most critical requirement?
15 Domain Requirement: Train protection system The deceleration of the train shall be computed as:Dtrain = Dcontrol + Dgradientwhere Dgradient is 9.81ms2 * compensated gradient/alpha and where thevalues of 9.81ms2 /alpha are known for different types of train.ProblemsUnderstandabilityRequirements are expressed in the language of the application domainThis is often not understood by software engineersImplicitnessDomain specialists understand the area so well that they do not think of making the domain requirements explicit
16 Requirements document requirements Specify external system behaviourSpecify implementation constraintsEasy to changeServe as reference tool for maintenanceRecord forethought about the life cycle of the systemi.e. predict changesCharacterise responses to unexpected events
19 Feasibility studiesA feasibility study decides whether or not the proposed system is worthwhileA short focused study that checksIf the system contributes to organisational objectivesIf the system can be engineered using current technology and within budgetIf the system can be integrated with other systems that are used
20 Elicitation and analysis Sometimes called requirements elicitation or requirements discoveryInvolves technical staff working with customers to find out aboutthe application domainthe services that the system should providethe system’s operational constraintsMay involve end-users, managers, engineers involved in maintenance, domain experts, trade unions, etc.These are called stakeholders
21 Problems of requirements analysis Stakeholders don’t know what they really wantStakeholders express requirements in their own termsDifferent stakeholders may have conflicting requirementsOrganisational and political factors may influence the system requirementsThe requirements change during the analysis processNew stakeholders may emerge and the business environment change
22 System modelsDifferent models may be produced during the requirements analysis activityRequirements analysis may involve three structuring activities which result in these different modelsPartitioning – Identifies the structural (part-of) relationships between entitiesAbstraction – Identifies generalities among entitiesProjection – Identifies different ways of looking at a problemSystem models will be covered on January 30
23 ScenariosScenarios are descriptions of how a system is used in practiceThey are helpful in requirements elicitation as people can relate to these more readily than abstract statement of what they require from a systemScenarios are particularly useful for adding detail to an outline requirements description
24 Requirements validation Concerned with demonstrating that the requirements define the system that the customer really wantsRequirements error costs are high so validation is very importantFixing a requirements error after delivery may cost up to 100 times the cost of fixing an implementation errorRequirements checkingValidityConsistencyCompletenessRealismVerifiability
25 Requirements validation techniques ReviewsSystematic manual analysis of the requirementsPrototypingUsing an executable model of the system to check requirements.Test-case generationDeveloping tests for requirements to check testabilityAutomated consistency analysisChecking the consistency of a structured requirements description
26 Key pointsRequirements set out what the system should do and define constraints on its operation and implementationFunctional requirements set out services the system should provideNon-functional requirements constrain the system being developed or the development processThe requirements engineering process includes a feasibility study, requirements elicitation and analysis, requirements specification and requirements managementRequirements validation is concerned with checks for validity, consistency, completeness, realism and verifiability