Unit 3- requirements for software development
- 2. Topics covered fFunctional and non-functional requirements User requirementsq System requirements Interface specification The software requirements documentThe software requirements document
- 3. Requirements engineering The process of establishing the servicesservices that the customer requires from a system and thecustomer requires from a system and the constraintsconstraints under which it operates and is developed.
- 4. Understanding the Importance of Requirements
- 6. Requirements imprecision P bl i h i t tt i li l t t dt t dProblems arise when requirements areare notnot preciselyprecisely statedstated.. AmbiguousAmbiguous requirementsrequirements may be interpreted in different ways by developers and usersusers. Consider the term ‘appropriate‘appropriate viewers’viewers’ • User intention - special purpose viewer for each different document type;document type; • Developer interpretation - Provide a text viewer that h th t t f th d tshows the contents of the document.
- 7. Requirements completeness and consistency I i i l i t h ld b b th l t dIn principle, requirements should be both complete and consistent. Complete • They should include descriptions of all facilities required. Consistent • There should be no conflicts or contradictions in the• There should be no conflicts or contradictions in the descriptions of the system facilities.
- 9. Classification of RequirementsClassification of Requirements
- 10. Functional and non-functional requirements Functional requirementsq • Statements of servicesservices the system should provide, how the system should react to particularparticular inputsinputs and how thesystem should react to particularparticular inputsinputs and how the system should behavebehave in particular situations. Non functional requirements( f )Non-functional requirements(performance) • constraints on the services or functions offered by the system such as timingtiming constraintsconstraints, constraints on the developmentdevelopment processprocess,, standardsstandards, etc.
- 11. Functional requirements D ib f ti lit t iDescribe functionality or system services. Depend on the typetype ofof softwaresoftware, expected users and the type of system where the software is used.
- 12. The LIBSYS system A lib t th t id i l i t f t b fA library system that provides a single interface to a number of databases of articlesarticles inin differentdifferent librarieslibraries.. Users can search for, download and print these articles for personal study.
- 13. Examples of functional requirements The user shall be able to search either all of the initialinitial setset of databases or select a subsetsubset from it. The system shall provide appropriateappropriate viewersviewers for the user to read documents in the document store. Every order shall be allocated a uniqueunique identifieridentifier (ORDER_ID) which the user shall be able to copy to the account’s permanentwhich the user shall be able to copy to the account s permanent storage area.
- 14. Non-functional requirements Th d fi t ti d t i t li bilitli bilitThese define system properties and constraints e.g. reliabilityreliability, responseresponse timetime and storagestorage requirementsrequirements. Constraints are I/O device capability, system representations, etc. Process requirements may also be specified mandating a particular CASE system, programming language or development method. Non-functional requirements may be moremore criticalcritical than functional requirements If these are not met the system isfunctional requirements. If these are not met, the system is useless.
- 15. Non-functional classifications Product requirementsq • Requirements which specify that the delivereddelivered productproduct must behave in a particular way e.g. execution speed, reliability, etc.p y g p , y, Organisational requirements • Requirements which are a consequence of organisationalorganisational• Requirements which are a consequence of organisationalorganisational policiespolicies and procedures e.g. process standards used, implementation requirements etcimplementation requirements, etc. External requirements • Requirements which arise fromfrom factorsfactors which are external to the system and its development process e.g. interoperability i t l i l ti i t trequirements, legislative requirements, etc.
- 17. Requirements measures Property Measure Speed Processed transactions/second User/Event response timeUser/Event response time Screen refresh time Size M Bytes Number of ROM chips Ease of use Training time Number of help frames Reliability Mean time to failure Probability of unavailability Rate of failure occurrence Availability Robustness Timeto restart after failureRobustness Timeto restart after failure Percentage of events causing failure Probability of data corruption on failure Portability Percentage of target dependent statements Number of target systems
- 18. Domain requirements D i d f th li ti d i d d ib tDerived from the application domain and describe system characteristics and features that reflect the domain. Domain requirements be new functional requirements, constraints on existing requirements or define specific computations. If domain requirements are not satisfied, the system may be unworkable.
- 19. LIBSYS requirement LIBSYS shall provide a financial accounting system that maintains records of all payments made by users of the system. System managers may configure this system so that regular users may receive discounted rates.y
- 20. Requirement problems D t b i t i l d b th t l d d t il dDatabase requirements includes both conceptual and detailed information • Describes the concept of a financial accounting system that is to be included in LIBSYS;
- 21. Domain requirements problems U d t d bilitUnderstand ability • Requirements are expressed in the language of the application domain; • This is often not understood by software engineers developing the system. Implicitness • Domain specialists understand the area so well that they do not think of making the domain requirements explicit.g q p
- 22. User requirements Sh ld d ib f ti lf ti l d f ti lf ti l i t iShould describe functionalfunctional and nonnon--functionalfunctional requirements in such a way that they are understandable by system users who d ’t h d t il d t h i l k l ddon’t have detailed technical knowledge. User requirements are defined using natural languagenatural language,, tablestables and diagramsdiagrams as these can be understood by all users.
- 23. Problems with natural language L k f l itLack of clarity • Precision is difficult without making the document difficult to read. Requirements confusion • Functional and non-functional requirements tend to be mixed-up. Requirements amalgamation • Several different requirements may be expressed together.Several different requirements may be expressed together.
- 24. Problems with NL specification A bi itAmbiguity • The readers and writers of the requirement must interpret the same words in the same way. NL is naturally ambiguous so this is very difficult. Over-flexibility • The same thing may be said in a number of different ways in the specification.
- 25. Guidelines for writing requirements Invent a standard format and use it for all requirements. Use language in a consistent wayUse language in a consistent way. Use text highlighting to identify key parts of the requirement. A id th f t jAvoid the use of computer jargon.
- 26. Alternatives to NL specification N t ti D i tiNotation Description Structured natural language This approach depends on defining standard forms or templates to express the requirements specification.g g q p Design description This approach uses a language like a programming language but with more abstract features to specify the requirements by defining an operational model of the system. This languages approach is not now widely used although it can be useful for interface specifications. Graphical notations A graphical language, supplemented by text annotations is used to define the functional requirements for the system An early example of such a graphical language was SADTnotations requirements for the system. An early example of such a graphical language was SADT. Now, use-case descriptions and sequence diagrams are commonly used . Mathematical These are notations based on mathematical concepts such as finite-state machines or specifications sets. These unambiguous specifications reduce the arguments between customer and contractor about system functionality. However, most customers don’t understand formal specifications and are reluctant to accept it as a system contract.p p y
- 27. Structured language specifications Th f d f th i t it i li it d b d fi dThe freedom of the requirements writer is limited by a predefined templatetemplate for requirements. All requirements are written in a standardstandard wayway. The terminology used in the description may be limited. The advantage is that the most of the expressiveness of natural language is maintained but a degreedegree ofof uniformityuniformity is imposed on the specification.
- 28. Form-based specifications D fi iti f th f ti titDefinition of the function or entity. Description of inputs and where they come from. Description of outputs and where they go to. Indication of other entities required. Pre and post conditions (if appropriate). The side effects (if any) of the function.The side effects (if any) of the function.
- 29. Form-based node specification Insulin Pump/Control Software/SRS/3.3.2 Function Compute insulin dose: Safe sugar level Description Computes the dose of insulin to be delivered when the current measured sugar level is in the safe zone between 3 and 7 units. Inputs Current sugar reading (r2), the previous two readings (r0 and r1) Source Current sugar reading from sensor. Other readings from memory. Outputs CompDose – the dose in insulin to be delivered Destination Main control loop Action: CompDose is zero if the sugar level is stable or falling or if the level is increasing but the t f i i d i If th l l i i i d th t f i i i i th C D irate of increase is decreasing. If the level is increasing and the rate of increase is increasing, then CompDose is computed by dividing the difference between the current sugar level and the previous level by 4 and rounding the result. If the result, is rounded to zero then CompDose is set to the minimum dose that can be delivered. Requires Two previous readings so that the rate of change of sugar level can be computedRequires Two previous readings so that the rate of change of sugar level can be computed. Pre-condition The insulin reservoir contains at least the maximum allowed single dose of insulin.. Post-condition r0 is replaced by r1 then r1 is replaced by r2 Side-effects NoneSide effects None
- 30. Tabular specification Used to supplement natural languageUsed to supplement natural language. Particularly useful when you have to define a number of possible alternative courses of action. Condition Action Sugar level falling (r2 < r1) CompDose = 0Sugar level falling (r2 < r1) CompDose 0 Sugar level stable (r2 = r1) CompDose = 0 Sugar level increasing and rate of CompDose = 0g g increase decreasing ((r2-r1)<(r1-r0)) p Sugar level increasing and rate of increase stable or increasing. ((r2-r1) CompDose = round ((r2-r1)/4) If rounded result = 0 thenincrease stable or increasing. ((r2 r1) (r1-r0)) If rounded result 0 then CompDose = MinimumDose
- 31. Graphical models G hi l d l t f l h d t h hGraphical models are most useful when you need to show how state changes or where you need to describe a sequence ofsequence of titiactions.actions.
- 32. Sequence diagrams Th h th f t th t t k l d iThese show the sequence of events that take place during some user interaction with a system. You read them from top to bottom to see the order of the actions that take place. Cash withdrawal from an ATM • Validate card; • Handle request; • Complete transaction.Complete transaction.
- 33. Sequence diagram of ATM withdrawal
- 36. Interface specification M t t t t ith tht ith th t d th tiMost systems must operate with otheroperate with other systems and the operating interfaces must be specified as part of the requirements. Three types of interfaceThree types of interface may have to be defined • Procedural interfaces; • Data structures that are exchanged; • Data representations.p Formal notationsFormal notations are an effective technique for interface specification.specification.
- 37. The requirements document Th i t d ti t d t i th ffi i l t t t f h t iThe requirements documentrequirements document is the official statement of what is required of the system developers. 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 of WHATWHAT the system should do rather than HOWHOW it should do it
- 38. Users of a requirements document
- 39. IEEE requirements standard D fi i t t f i t d t th t tDefines a generic structure for a requirements document that must be instantiated for each specific system. • Introduction. • General description. • Specific requirements. • Appendices.pp • Index.
- 40. Requirements document structure P fPreface Introduction Glossary User requirements definition System architectureSystem architecture System requirements specification System models System evolutionSystem evolution Appendices
- 42. Topics covered Feasibility studies Requirements elicitation and analysisq y Requirements validation Requirements management
- 43. Requirements Engineering Processes Th d f RE id l d di thThe 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 elicitation;q ; • Feasibility study; R i t l i• Requirements analysis; • Requirements validation; • Requirements management.
- 44. The requirements engineering process
- 45. Feasibility studies A f ibilit t d d id h th t th d tA feasibility study decides whether or not the proposed system is worthwhileworthwhile..
- 46. Feasibility study implementation B d i f ti t ( h t i i d)Based on information assessment (what is required), information collection and report writing. Questions for people in the organisation • What if the system wasn’t implemented? • What are current process problems? • How will the proposed system help?• How will the proposed system help? • What will be the integration problems? • Is new technology needed? What skills? • What facilities must be supported by the proposed system?
- 47. Elicitation and analysis S ti ll d i t li it ti i ti tSometimes called requirements elicitation or requirementsrequirements discoverydiscovery.. 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 iny , g , g maintenance, domain experts, trade unions, etc. These are called stakeholdersstakeholders..called stakeholdersstakeholders..
- 48. Problems of requirements analysis 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 systemOrganisational and political factors may influence the system requirements. The requirements change during the analysis process. New stakeholders may emerge and the business environment change.
- 49. Process activities Requirements discoveryq y • Interacting with stakeholders to discover their requirements. Domain requirements are also discovered at this stage.Domain requirements are also discovered at this stage. Requirements classification and organisation • Groups related requirements and organises them into coherent• Groups related requirements and organises them into coherent clusters. Prioritisation and negotiationPrioritisation and negotiation • Prioritising requirements and resolving requirements conflicts. Requirements documentation • Requirements are documented and input into the next round of the spiral.
- 51. ATM stakeholders B k tBank customers Representatives of other banks Bank managers Counter staff Database administrators S itSecurity managers Marketing department Hardware and software maintenance engineers Banking regulatorsg g
- 52. Viewpoints Vi i t f t t it t i th i t t tViewpoints are a way of structuringstructuring the requirements to represent the perspectivesperspectives of different stakeholders. Stakeholders may be classified under different viewpoints. This multi-perspective analysis is important as there is no single correct way to analyse system requirements.
- 53. Types of viewpoint InteractorInteractor viewpointsviewpointsInteractorInteractor viewpointsviewpoints • People or other systems that interact directly with the system. In an ATM the customer’s and the account database arean ATM, the customer s and the account database are interactor VPs. IndirectIndirect viewpointsviewpointsIndirectIndirect viewpointsviewpoints • Stakeholders who do not use the system themselves but who influence the requirements In an ATM management andinfluence the requirements. In an ATM, management and security staff are indirect viewpoints. DomainDomain viewpointsviewpointsDomainDomain viewpointsviewpoints • Domain characteristics and constraints that influence the requirements In an ATM an example would be standards forrequirements. In an ATM, an example would be standards for inter-bank communications.
- 54. Viewpoint identification Id tif i i t iIdentify viewpoints using • Providers and receivers of system services; • Systems that interact directly with the system being specified; • Regulations and standards; • Sources of business and non-functional requirements.q • Engineers who have to develop and maintain the system; • Marketing and other business viewpoints• Marketing and other business viewpoints.
- 55. LIBSYS viewpoint hierarchy All VPs InteractorIndirect Domain Article providers FinanceLibrary manager Library staff Users Classification system UI standards ExternalStaffStudents Cataloguers System managers
- 56. Interviewing I f l i f l i t i i th RE t t titiIn formal or informal interviewing, the RE team puts questionsquestions to stakeholders about the system that they use and the system to b d l dbe developed. There are two types of interview •• ClosedClosed interviewsinterviews where a pre-defined set of questions are answered. •• OpenOpen interviewsinterviews where there is no pre-defined agenda and a range of issues are explored with stakeholders.
- 57. Scenarios S i l lif l f h t b dScenarios are real-life examples of how a system can be used. They should include • A description of the startingstarting situationsituation; • A description of the normalnormal flowflow ofof eventsevents; • A description of whatwhat cancan gogo wrongwrong; • Information about other concurrentconcurrent activitiesactivities;Information about other concurrentconcurrent activitiesactivities; • A description of the statestate whenwhen thethe scenarioscenario finishesfinishes.
- 58. LIBSYS scenario (1) InitialInitial assumptionassumption: The user has loggedlogged on to the LIBSYS system and has located the journaljournal containing the copy of the article. NormalNormal:: The user selects the article to be copied He or she is then prompted by theNormalNormal:: The user selects the article to be copied. He or she is then prompted by the system to either provide subscribersubscriber informationinformation for the journal or to indicate how they will pay for the article. Alternative payment methods are by credit card or byy p y p y y y quoting an organisational account number. The user is then asked to fill in a copyright form that maintains details of the transaction and they then submit this to the LIBSYS system. The copyright form is checked and, if OK, the PDF version of the article is downloaded to the LIBSYS working area on the user’s computer and the user isdownloaded to the LIBSYS working area on the user s computer and the user is informed that it is available. The user is asked to select a printer and a copy of the article is printed. If the article has been flagged as ‘print-only’ it is deleted from the user’s system once the user has confirmed that printing is complete.
- 59. LIBSYS scenario (2) WhatWhat cancan gogo wrongwrong: The user may fail to fill in the copyrightcopyright formform correctlycorrectly In thisWhatWhat cancan gogo wrongwrong: The user may fail to fill in the copyrightcopyright formform correctlycorrectly. In this case, the form should be re-presented to the user for correction. If the resubmitted form is still incorrect then the user’s request for the article is rejected. The payment may be rejected by the system. The user’s request for the article is rejected. The article download may fail. Retry until successful or the user terminates the session. It may not be possible to print the article If the article is not flagged as ‘print-only’ thenIt may not be possible to print the article. If the article is not flagged as print-only then it is held in the LIBSYS workspace. Otherwise, the article is deleted and the user’s account credited with the cost of the article. OtherOther activitiesactivities: Simultaneous downloads of other articles. SystemSystem statestate onon completioncompletion:: User is logged on. The downloaded article has been deleted from LIBSYS workspace if it has been flagged as print-only.
- 60. Use cases U i b d t h i i th UML hi hUse-cases are a scenario based technique in the UML which identify the actorsactors in an interaction and which describe the interaction itself. A set of use cases should describe all possible interactions with the system. SequenceSequence diagramsdiagrams may be used to add detail to use-cases byqq gg y y showing the sequence of event processing in the system.
- 62. LIBSYS use cases
- 63. Print article sequence User item: Article copyrightForm: Form myWorkspace: W orkspace myPrinter: Printe r request complete request returnreturn copyright OK deliver article OK print send confirminform delete
- 64. Ethnography-Observational technique A i l i ti t d id bl ti b ib i ddA social scientists spends a considerable time observingobserving andand analysinganalysing how people actually work. People do not have to explain or articulate their work. Social and organisational factors of importance may be observed. Ethnographic studies have shown that work is usually richerEthnographic studies have shown that work is usually richer and more complex than suggested by simple system models.
- 65. Focused ethnography D l d i j t t d i th i t ffi t lDeveloped in a project studying the air traffic control process Combines ethnography with prototyping Prototype development results in unanswered questions which focus the ethnographic analysis. The problem with ethnography is that it studies existing practices which may have some historical basis which is no longer relevant.
- 66. Ethnography and prototyping Ethno g raphic anal ysis De briefing meetings Focused ethno g raph yanal ysis meetings ethno g raph y Prototype evaluation Generic system de velopment System proto yping
- 67. Scope of ethnography R i t th t d i d f th th t l t llRequirements that are derived from the way that people actually work rather than the way which process definitions suggest that th ht t kthey ought to work. Requirements that are derived from cooperation and awareness of other people’s activities.
- 68. Requirements validation C d ith d t ti th t th i t d fi thConcerned with demonstrating that the requirements define the system that the customercustomer reallyreally wantswants.. 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.
- 69. Requirements checking V liditV lidit D th t id th f ti hi h b tValidityValidity.. Does the system provide the functions which best support the customer’s needs? ConsistencyConsistency.. Are there any requirements conflicts? CompletenessCompleteness. Are all functions required by the customer included? RealismRealism Can the requirements be implemented given availableRealismRealism. Can the requirements be implemented given available budget and technology V ifi bilitV ifi bilit C th i t b h k d?VerifiabilityVerifiability. Can the requirements be checked?
- 70. Requirements validation techniques Requirements reviewsRequirements reviews • Systematic manual analysis of the requirements. PrototypingPrototyping • Using an executable model of the system to check• Using an executable model of the system to check requirements. T tT t titiTestTest--case generationcase generation • Developing tests for requirements to check testability.
- 71. Requirements reviews R l i h ld b h ld hil th i t d fi itiRegular 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.
- 72. Review checks V ifi bilit I th i t li ti ll t t bl ?Verifiability. Is the requirement realistically testable? Comprehensibility. Is the requirement properly understood? Traceability. Is the origin of the requirement clearly stated? Adaptability. Can the requirement be changed without a large impact on other requirements?
- 73. Requirements management Req irements management is the process of managingmanaging changingchangingRequirements management is the process of managingmanaging changingchanging requirementsrequirements during the requirements engineering process and system developmentsystem development.
- 74. Requirements change Th i it f i t f diff t i i t hThe 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.
- 75. Requirements management planning During the requirements engineering process, you have to plan:g q g g p , y p • Requirements identification • How requirements are individually identified;How requirements are individually identified; • A change management process • The process followed when analysing a requirements change;The process followed when analysing a requirements change; • Traceability policies • The amount of information about requirements relationships that is• The amount of information about requirements relationships that is maintained; • CASE tool supportCASE tool support • The tool support required to help manage requirements change;
- 76. Requirements change management Sh ld l t ll d h t th i tShould apply to all proposed changes to the requirements. Principal stages • Problem analysis. 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.g
- 78. Unit Review Questions 1 What are the differences between requirements definition and requirements1. What are the differences between requirements definition and requirements specification? 2. Explain the software (system) requirement classification in detail with example 3. Describe different software requirements with examples. 4. Explain the characteristic features and Structure of a software requirementsStructure of a software requirements documentdocumentdocument.document. 5. Describe major activities of requirements engineering processmajor activities of requirements engineering process. 6. What are the various techniques used for requirements elicitationtechniques used for requirements elicitation and analysis? Explain any one in detail. 7. Explain the salient features of View point, stockholdersView point, stockholders and scenario techniques.scenario techniques. W it h t t8. Write short notes on: a. Ethnography b. Use-case c. Sequence diagram d. Feasibility study e. Volatile requirements e. Require change management.q q g g 9. What is requirement validation ?is requirement validation ? Explain different requirements validation techniques.
- 79. D ib j ti iti f i t i iDescribe major activities of requirements engineering process.