Transcription
What is a requirement? May range fromSoftware RequirementsDescriptions and specificationsof a system– a high-level abstract statement of a serviceor– a statement of a system constraint to adetailed mathematical functional specification Requirements may be used for– a bid for a contract must be open to interpretation– the basis for the contract itself must be defined in detail Both the above statements may be calledrequirementsExampleExample 4.A.5 The database shall support the generation and control ofconfiguration objects; that is, objects which are themselves groupingsof other objects in the database. The configuration control facilitiesshall allow access to the objects in a version group by the use of anincomplete name. 1
Types of requirements Written for customers– User requirements Statements in natural language plus diagrams of theservices the system provides and its operationalconstraints. Written as a contract between client andcontractor– System requirementsUser requirements readers Client managersSystem end-usersClient engineersContractor managersSystem architects A structured document setting out detaileddescriptions of the system services. Written for developers– Software specification A detailed software description which can serve as abasis for a design or implementation.System requirements readers System end-usersClient engineersSystem architectsSoftware developersSoftware specification readers Client engineers (maybe) System architects Software developers2
Functional requirementsWe will come back to userand system requirementsFunctional requirements Describe functionality or system services Depend on the type of software,expected users and the type of systemwhere the software is used Functional user requirements may behigh-level statements of what thesystem should do but functional systemrequirements should describe the systemservices in detail Statements of services the systemshould provide, how the systemshould react to particular inputsand how the system should behavein particular situations.Examples of functionalrequirements1. The user shall be able to search eitherall of the initial set of databases orselect a subset from it.2. The system shall provide appropriateviewers for the user to read documentsin the document store.3. Every order shall be allocated a uniqueidentifier (ORDER ID) which the usershall be able to copy to the account’spermanent storage area.3
Requirements imprecision Problems arise when requirements arenot precisely stated Ambiguous requirements may beinterpreted in different ways bydevelopers and users Consider the term ‘appropriate viewers’– User intention - special purpose viewer foreach different document type– Developer interpretation - Provide a textviewer that shows the contents of thedocumentWhat requirements are these? It shall be possible for all necessarycommunication between the APSE and theuser to be expressed in the standardAda character set The system development process anddeliverable documents shall conform tothe process and deliverables defined inXYZCo-SP-STAN-95 The system shall not disclose anypersonal information about customersapart from their name and referencenumber to the operators of the systemRequirements completeness andconsistency In principle, requirements should be bothcomplete and consistent Complete– They should include descriptions of allfacilities required Consistent– There should be no conflicts orcontradictions in the descriptions of thesystem facilities In practice, it is difficult (?impossible?)to produce a complete and consistentrequirements documentNon-functional requirements constraints on the services orfunctions offered by the systemsuch as timing constraints,constraints on the developmentprocess, standards, etc.4
Non-functional requirementsNon-functional classifications Define system properties and constraintse.g. reliability, response time andstorage requirements. Constraints are I/O device capability, systemrepresentations, etc. Process requirements may also bespecified mandating a particular system,programming language or developmentmethod Non-functional requirements may bemore critical than functionalrequirements. If these are not met, thesystem is useless Product requirementsNon-functional requirementtypesNon-functional requirementsexamples– Requirements which specify that thedelivered product must behave in a particularway e.g. execution speed, reliability, etc. Organizational requirements– Requirements which are a consequence oforganizational policies and procedures e.g.process standards used, implementationrequirements, etc. External requirements– Requirements which arise from factors whichare external to the system and itsdevelopment process e.g. interoperabilityrequirements, legislative requirements, etc. Product requirement– 4.C.8 It shall be possible for all necessarycommunication between the APSE and the user tobe expressed in the standard Ada character set Organizational requirement– 9.3.2 The system development process anddeliverable documents shall conform to theprocess and deliverables defined in XYZCo-SPSTAN-95 External requirement– 7.6.5 The system shall not disclose any personalinformation about customers apart from theirname and reference number to the operators ofthe system5
Goals and requirements Non-functional requirements may be verydifficult to state precisely and impreciserequirements may be difficult to verify. Goal– A general intention of the user such as easeof use Verifiable non-functional requirement– A statement using some measure that can beobjectively tested Goals are helpful to developers as theyconvey the intentions of the systemusersRequirements measuresPropertyMeasureSpeed Processed transactions/second User/event response time Screen refresh timeSize K Bytes Number of RAM chipsEase of use Training time Number of help framesReliability Mean time to failure Probability of unavailability Rate of failure occurrence AvailabilityRobustness Time to restart after failure Percentage of events causing failure Probability of data corruption on failurePortability Percentage of target dependent statements Number of target systemsExamples A system goal– The system should be easy to use byexperienced controllers and should beorganized in such a way that user errors areminimized. A verifiable non-functional requirement– Experienced controllers shall be able to useall the system functions after a total of twohours training. After this training, theaverage number of errors made byexperienced users shall not exceed two perday.Requirements interaction Conflicts between different nonfunctional requirements are common incomplex systems Spacecraft system– To minimize weight, the number of separatechips in the system should be minimized– To minimize power consumption, lower powerchips should be used– However, using low power chips may meanthat more chips have to be used. Which isthe most critical requirement?6
Domain requirements Requirements that come from theapplication domain of the systemand that reflect characteristics ofthat domainLibrary system domainrequirements There shall be a standard user interfaceto all databases which shall be based onthe Z39.50 standard. Because of copyright restrictions, somedocuments must be deleted immediatelyon arrival. Depending on the user’srequirements, these documents willeither be printed locally on the systemserver for manually forwarding to theuser or routed to a network printer.Domain requirements Derived from the application domain anddescribe system characteristics andfeatures that reflect the domain May be new functional requirements,constraints on existing requirements ordefine specific computations If domain requirements are notsatisfied, the system may be unworkableDomain requirements problems Understandability– Requirements are expressed in thelanguage of the application domain– This is often not understood bysoftware engineers developing thesystem Implicitness– Domain specialists understand the areaso well that they do not think ofmaking the domain requirementsexplicit7
User requirementsBack to user and systemrequirementsDatabase requirement 4.A.5 The database shall support the generation and control ofconfiguration objects; that is, objects which are themselves groupingsof other objects in the database. The configuration control facilitiesshall allow access to the objects in a version group by the use of anincomplete name. Should describe functional and nonfunctional requirements so thatthey are understandable by systemusers who don’t have detailedtechnical knowledge User requirements are defined usingnatural language, tables anddiagramsRequirement problems Database requirements includesboth conceptual and detailedinformation– Describes the concept of configurationcontrol facilities– Includes the detail that objects maybe accessed using an incomplete name8
Editor 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 anoption on the control panel. Initially, the grid is off. The grid may beturned on and off at any time during an editing session and can betoggled between inches and centimetres at any time. A grid optionwill be provided on the reduce-to-fit view but the number of gridlines shown will be reduced to avoid filling the smaller diagramwith grid lines. Requirement problems Grid requirement mixes threedifferent kinds of requirement– Conceptual functional requirement (theneed for a grid)– Non-functional requirement (grid units)– Non-functional UI requirement (gridswitching)Problems with natural language Lack of clarityWhy the problems?– Precision is difficult without makingthe document difficult to read Requirements confusion– Functional and non-functionalrequirements tend to be mixed-up Requirements mix-up– Several different requirements maybe expressed together9
Structured presentationDetailed user requirementGuidelines for writingrequirementsSystem requirements Invent a standard format and use itfor all requirements Use language in a consistent way.Use “shall” for mandatoryrequirements, “should” for desirablerequirements Use text highlighting to identifykey parts of the requirement Avoid the use of computer jargon More detailed specifications of userrequirements Serve as a basis for designing thesystem May be used as part of the systemcontract10
Problems with NL specificationAlternatives to NL specification Ambiguity– The readers and writers of the requirementmust interpret the same words in the sameway. NL is naturally ambiguous so this isvery difficult Over-flexibility– The same thing may be said in a number ofdifferent ways in the specification Lack of modularisation– NL structures are inadequate to structuresystem requirementsStructured languagespecifications A limited form of natural languagemay be used to expressrequirements This removes some of the problemsresulting from ambiguity andflexibility and imposes a degree ofuniformity on a specification Often best supported using aforms-based approachForm-based specifications Definition of the function or entity Description of inputs and wherethey come from Description of outputs and wherethey go to Indication of other entities required Pre and post conditions (ifappropriate) The side effects (if any)11
Form-based node specificationPDL-based requirementsdefinition Requirements may be defined using alanguage like a programming language butwith more flexibility of expression Most appropriate in two situations Where an operation is specified as a sequence ofactions and the order is important When hardware and software interfaces have to bespecified Disadvantages are– The program definition language (PDL) maynot be sufficiently expressive to definedomain concepts– The specification will be taken as a designrather than a specificationPart of an ATM specificationPDL disadvantages PDL may not be sufficiently expressiveto express the system functionality in anunderstandable way Notation is only understandable to peoplewith programming language knowledge The requirement may be taken as adesign specification rather than a modelto help understand the system12
Interface specificationPDL interface description Most systems must operate with othersystems and the operating interfacesmust be specified as part of therequirements Three types of interface may have to bedefined– Procedural interfaces– Data structures that are exchanged– Data representations Formal notations are an effectivetechnique for interface specificationViewpoint-oriented elicitation Stakeholders represent differentways of looking at a problem orproblem viewpoints This multi-perspective analysis isimportant as there is no singlecorrect way to analyze systemrequirementsBanking ATM system The example used here is an auto-tellersystem which provides some automatedbanking services I use a very simplified system whichoffers some services to customers of thebank who own the system and a narrowerrange of services to other customers Services include cash withdrawal,message passing (send a message torequest a service), ordering a statementand transferring funds13
Autoteller viewpoints Bank customers Representatives of other banks Hardware and software maintenanceengineers Marketing department Bank managers and counter staff Database administrators and securitystaff Communications engineers Personnel departmentExternal viewpoints Natural to think of end-users asreceivers of system services Viewpoints are a natural way tostructure requirements elicitation It is relatively easy to decide if aviewpoint is valid Viewpoints and services may beused to structure non-functionalrequirementsTypes of viewpoints– Data sources or sinks Viewpoints are responsible for producing or consumingdata. Analysis involves checking that data is produced andconsumed and that assumptions about the source andsink of data are valid– Representation frameworks Viewpoints represent particular types of systemmodel. These may be compared to discover requirementsthat would be missed using a single representation.Particularly suitable for real-time systems– Receivers of services Viewpoints are external to the system and receiveservices from it. Most suited to interactive systemsMethod-based analysis Widely used approach to requirementsanalysis. Depends on the application of astructured method to understand thesystem Methods have different emphases. Someare designed for requirements elicitation,others are close to design methods A viewpoint-oriented method (VORD) isused as an example here. It alsoillustrates the use of viewpoints14
VORD process modelThe VORD method Viewpoint identificationViewpointIdentification– Discover viewpoints which receive systemservices and identify the services provided toeach viewpointViewpointStructuring Viewpoint structuring– Group related viewpoints into a hierarchy.Common services are provided at higherlevels in the hierarchyViewpointDocumentation Viewpoint documentationViewpointSystemMapping– Refine the description of the identifiedviewpoints and services Viewpoint-system mapping– Transform the analysis to an object-orienteddesignVORD standard formsViewpoint UserinterfaceSystem 5
Viewpoint service information1.2.3.4.5.6.7.Account HolderForeign CustomerBank TellerService ListService ListService ListWithdraw cashQuery balanceOrder checksSend messageTransaction listOrder statementTransfer funds1. Withdraw cash2. Query balance1.2.3.4.Run diagnosticsAdd cashAdd paperSend MessageViewpoint hierarchyServicesWithdraw cashQuery balanceServicesOrder checksSend messageTransaction listOrder statementTransfer fundsViewpoint data/controlAccountHolderControl Input1.2.3.4.Data InputStart transactionCancel transactionEnd transactionSelect service1.2.3.4.Card detailsPINAmount requiredMessageCustomer/cash withdrawaltemplates Reference– Customer Rationale– Account number– PIN– Start transaction Specification VPs– Cash withdrawal– Balance enquiry Non-functional requirements– Account holder– Foreign customer Provider Reference Attributes Events– Select service– Cancel transaction– End transaction Services Sub-VPs– Cash withdrawal– To improve customer serviceand reduce paperwork– Users choose this service bypressing the cash withdrawalbutton. They then enter theamount required. This isconfirmed and, if the fundsare low, the balance isdelivered– Customer– Deliver cash within 1 minuteof amount being confirmed– Filled in later16
Scenarios Scenarios are descriptions of how asystem is used in practice They are helpful in requirementselicitation as people can relate tothese more readily than abstractstatement of what they requirefrom a system Scenarios are particularly useful foradding detail to an outlinerequirements descriptionScenario descriptions System state at the beginning ofthe scenario Normal flow of events in thescenario What can go wrong and how this ishandled Other concurrent activities System state on completion of thescenarioEvent scenario - starttransactionEllipses. data provided from orEvent scenarios Event scenarios may be used todescribe how a system responds tothe occurrence of some particularevent such as ‘start transaction’ VORD includes a diagrammaticconvention for event scenarios.––––Data provided and deliveredControl informationException processingThe next expected eventCardCard presentdelivered to a viewpointRequest PINValid cardUser OKPINTimeoutReturn cardInvalid cardReturn cardStolen cardRetain cardAccountNumberPINValidate userAccountnumberSelectserviceControl information enters andleaves Incorrectat the PINtop of each boxRe-enter PINName of next event is inDatashadedleaves boxfrom theright ofeach boxIncorrectPINReturn cardExceptionsare shown at thebottom of each box17
Use casesLending use-case Use-cases are a scenario basedtechnique in the UML which identifythe actors in an interaction andwhich describe the interaction itself A set of use cases should describeall possible interactions with thesystemLending ServicesActorsLibrary use-casesLibraryuserSequence Diagrams Sequence diagrams may be used toadd detail to use-cases by showingthe sequence of event processing inthe systemLending ServicesUser administrationClass of InteractionsLibrarystaffSupplierCatalog Services18
Requirements engineeringprocessesCatalogue management:Sequence ogCataloguer:Library staffAcquireNewCatalog itemDispose The processes used for RE vary widelydepending on the application domain, thepeople involved and the organizationdeveloping the requirements However, there are a number of genericactivities common to all nagementUncatalog itemThe Requirements itation & RequirementsValidationSystemModelsUser & SystemRequirementsRequirementsDocumentFeasibility studies A feasibility study decides whetheror not the proposed system isworthwhile A short focused study that checks– If the system contributes toorganizational objectives– If the system can be engineered usingcurrent technology and within budget– If the system can be integrated withother systems that are used19
Feasibility study implementation Based on information assessment (what isrequired), information collection andreport writing Questions for people in the organization––––––What if the system wasn’t implemented?What are current process problems?How will the proposed system help?What will be the integration problems?Is new technology needed? What skills?What facilities must be supported by theproposed system?Elicit: by Webster dictionaryMain Entry: elic·itPronunciation: i-'li-s&tFunction: transitive verbEtymology: Latin elicitus, past participle ofelicere, from e- lacere to allureDate: 16051 : to draw forth or bring out (somethinglatent or potential) hypnotism elicited hishidden fears 2 : to call forth or draw out (asinformation or a response) her remarkselicited cheers ElicitationRequirements Analysis Sometimes called requirements elicitationor requirements discovery Involves technical staff working withcustomers to find out about theapplication domain, the services that thesystem should provide and the system’soperational constraints May involve end-users, managers,engineers involved in maintenance, domainexperts, trade unions, etc. These arecalled stakeholders Stakeholders don’t know what they reallywant Stakeholders express requirements intheir own terms Different stakeholders may haveconflicting requirements Organizational and political factors mayinfluence the system requirements The requirements change during theanalysis process. New stakeholders mayemerge and the business environmentchange20
The requirements equirementsDefinition uirementsCollectionConflictResolutionRequirements validation Concerned with demonstrating thatthe requirements define the systemthat the customer really wants Requirements error costs are highso validation is very important– Fixing a requirements error afterdelivery may cost up to 100 times thecost of fixing an implementation errorClassificationRequirements Validation Validity. Does the system provide thefunctions that best support thecustomer’s needs? Consistency. Are there any requirementsconflicts? Completeness. Are all functions requiredby the customer included? Realism. Can the requirements beimplemented given available budget andtechnology Verifiability. Can the requirements bechecked?Requirements validationtechniques Requirements reviews– Systematic manual analysis of therequirements Prototyping– Using an executable model of the system tocheck requirements. Test-case generation– Developing tests for requirements to checktestability Automated consistency analysis– Checking the consistency of a structuredrequirements description21
Requirements reviews Regular reviews should be held while therequirements definition is beingformulated Both client and contractor staff shouldbe involved in reviews Reviews may be formal (with completeddocuments) or informal. Goodcommunications between developers,customers and users can resolve problemsat an early stageRequirements management Requirements management is the processof managing changing requirements duringthe requirements engineering process andsystem development Requirements are inevitably incompleteand inconsistent– New requirements emerge during the processas business needs change and a betterunderstanding of the system is developed– Different viewpoints have differentrequirements and these are oftencontradictoryReview checks Verifiability. Is the requirementrealistically testable? Comprehensibility. Is therequirement properly understood? Traceability. Is the origin of therequirement clearly stated? Adaptability. Can the requirementbe changed without a large impacton other requirements?Requirements management planning During the requirements engineeringprocess, you have to plan:– Requirements identification How requirements are individually identified– A change management process The process followed when analyzing a requirementschange– Traceability policies The amount of information about requirementsrelationships that is maintained– CASE tool support The tool support required to help managerequirements change22
TraceabilityA traceability matrix Traceability is concerned with therelationships between requirements, theirsources and the system design Source traceability– Links from requirements to stakeholders whoproposed these requirements Requirements traceability– Links between dependent requirements Design traceability– Links from the requirements to the designU “uses the requirement”, R “Some other weaker relationship”CASE tool support Requirements storage– Requirements should be managed in a secure,managed data store Change management– The process of change management is aworkflow process whose stages can bedefined and information flow between thesestages partially automated Traceability management– Automated retrieval of the links betweenrequirements23
Enduring and volatilerequirements Enduring requirements. Stablerequirements derived from the coreactivity of the customer organisation.E.g. a hospital will always have doctors,nurses, etc. May be derived from domainmodels Volatile requirements. Requirementswhich change during development or whenthe system is in use. In a hospital,requirements derived from health-carepolicyRequirements change The priority of requirements fromdifferent viewpoints changes duringthe development process System customers may specifyrequirements from a businessperspective that conflict with enduser requirements The business and technicalenvironment of the system changesduring its development24
Requirements evolutionInitialunderstandingof problem Should apply to all proposed changes tothe requirements Principal stagesChangedunderstandingof problemInitialrequirementsRequirements change managementChangedrequirementsTimeRequirements change managementIdentified problemProblem analysisand change specificationChange analysisand costingChange implementation– Problem analysis. Discuss requirementsproblem and propose change– Change analysis and costing. Assess effectsof change on other requirements– Change implementation. Modify requirementsdocument and other documents to reflectchangeThe requirements document The requirements document is theofficial statement of what isrequired of the system developers Should include both a definition anda specification of requirements It is NOT a design document. Asfar as possible, it should set ofWHAT the system should do ratherthan HOW it should do itRevised requirements25
Users of a requirementsdocument– System customers Specify the requirements and read them to checkthat they meet their needs– Managers Use the requirements document to plan a bid for thesystem and to plan the system– System engineers Use the requirements to understand what system isto be developed– System test engineers Use the requirements to develop validation tests forthe system Requirements documentrequirementsSpecify external system behaviourSpecify implementation constraintsEasy to changeServe as reference tool for maintenanceRecord forethought about the life cycleof the system i.e. predict changes Characterise responses to unexpectedevents– System maintenance engineers Use the requirements to help understand the systemand the relationship between its partsIEEE requirements standard IntroductionGeneral descriptionSpecific requirementsAppendicesIndexThis is a generic structure thatmust be instantiated for specificsystems26
Non-functional requirement types Non-functional requirements examples Product requirement - 4.C.8 It shall be possible for all necessary communication between the APSE and the user to be expressed in the standard Ada character set Organizational requirement - 9.3.2 The system development process and
