Software System Engineering - Chapter 8

  • Published on

  • View

  • Download


Software System Engineering


  • 1. 1CCHHAAPPTTEERR 88RReeqquuiirreemmeennttss CCaappttuurreeSoftware SystemEngineering (260CT)

2. In This Lecture You Will Learn:The distinction between the current andrequired systemsWhen and how to apply the main factfinding techniquesThe roles played by usersThe need to document requirements2 3. 3User RequirementsNeed to understand how theorganization operates at presentWhat are the problems with the currentsystem?What are the requirements users have ofa new system that are not in the currentsystem? 4. Current SystemMuch of the current system meets theneeds of people who use itSections of the system no longer meetthe needs of the organizationSome aspects of the organizations workare not covered by the current systemThe system can no longer evolve butneeds to be replaced4 5. 5Current SystemIt is important to understand currentsystem to carry functionality forward intonew systemIt is also important to understand it sothat shortcomings and defects can becorrected in the new system 6. 6Current SystemYourdon (1989) argues against spendinga lot of time analysing the existingsystemits being replaced!SSADM makes the case for modellingthe current systemmuch of itsfunctionality will be required in the newsystem 7. 7Reasons for Investigatingthe Current System Functionality is required in new system Data must be migrated into new system Technical documentation provides details ofprocessing algorithms Defects of existing system must be avoided Parts of existing system may have to be kept We need to understand the work of the users Baseline information about the existing systemhelps set targets for the new one 8. New Requirements Organizations operate in a rapidly changingbusiness environment Organizations operate in a changing technicalenvironment Governments and supra-governmentalorganizations introduce legislation Organizations merge, demerge, take over andget taken over All this drives the need to replace systems andbuild new ones8 9. 9Types of RequirementsFunctionalNon-functionalUsability 10. Functional Requirements Describe what a system must do Include: processes interfaces with users and other systems what the system must hold data about Modelled with Use Case Diagrams. Later willbe modelled with other kinds of diagrams thatshow the structure of the system (ClassDiagrams) and its behaviour (InteractionDiagrams and Statechart Diagrams)10 11. Non-functional Requirements Concerned with how well the system performs Include: response times volumes of data security considerations Documented in Requirements List or in UseCase Model (for requirements that can belinked to specific use cases)11 12. Usability Requirements Concerned with matching the system to theway that people work Sets measurable objectives Include: characteristics of users tasks users undertake situational factors acceptance criteria for the working system Documented in Requirements List. May betested by Prototypes12 13. 13Fact Finding TechniquesBackground ReadingInterviewingObservationDocument SamplingQuestionnaires 14. Background ReadingAim is to understand the organizationand its business objectivesIncludes: reports organization charts policy manuals job descriptions documentation of existing systems14 15. 15Background ReadingAdvantages: helps to understand the organization beforemeeting the people who work there helps to prepare for other types of fact finding documentation of existing system may help toidentify requirements for functionality of newsystem 16. 16Background ReadingDisadvantages: written documents may be out of date or notmatch the way the organization reallyoperatesAppropriate situations: analyst is not familiar with organization initial stages of fact finding 17. 17InterviewingAim is to get an in-depth understandingof the organizations objectives, usersrequirements and peoples rolesIncludes: managers to understand objectives staff to understand roles and informationneeds customers and the public as potential users 18. 18InterviewingAdvantages: personal contact allows the inetrviewer torespond adaptively to what is said it is possible to probe in greater depth if the interviewee has little or nothing to say,the interview can be terminated 19. 19InterviewingDisadvantages: can be time-consuming and costly notes must be written up or tapes transcribedafter the interview can be subject to bias if interviewees provide conflicting informationthis can be difficult to resolve later 20. 20InterviewingAppropriate situations: most projects at the stage in fact finding when in-depthinformation is requiredRequires skill to carry out effectively(See Box 6.1 for guidelines) 21. 21Observation Aim is to see what really happens, not whatpeople say happens Includes: seeing how people carry out processes seeing what happens to documents obtaining quantitative data as baseline forimprovements provided by new system following a process through end-to-end Can be open-ended or based on a schedule 22. 22ObservationAdvantages: first-hand experience of how the systemoperates high level of validity of the data can beachieved verifies information from other sources allows the collection of baseline data 23. 23ObservationDisadvantages: people dont like being observed and maybehave differently, distorting the findings requires training and skill logistical problems for the analyst with staffwho work shifts or travel long distances ethical problems with personal data 24. 24ObservationAppropriate situations: when quantitative data is required to verify information from other sources when conflicting information from othersources needs to be resolved when a process needs to be understood fromstart to finish 25. 25Document Sampling Aims to find out the information requirementsthat people have in the current system Also aims to provide statistical data aboutvolumes of transactions and patterns of activity Includes: obtaining copies of empty and completed documents counting numbers of forms filled in and lines on the forms screenshots of existing computer systems 26. 26Document Sampling Advantages: for gathering quantitative data for finding out about error rates Disadvantages: not helpful if the system is going to changedramatically Appropriate situations: always used to understand information needs where large volumes of data are processed where error rates are high 27. 27QuestionnairesAims to obtain the views of a largenumber of people in a way that can beanalysed statisticallyIncludes: postal, web-based and email questionnaires open-ended and closed questions gathering opinion as well as facts 28. 28 29. 29QuestionnairesAdvantages: economical way of gathering information froma large number of people effective way of gathering information frompeople who are geographically dispersed a well designed questionnaire can beanalysed by computer 30. 30QuestionnairesDisadvantages: good questionnaires are difficult to design no automatic way of following up or probingmore deeply postal questionnaires suffer from lowresponse rates 31. 31QuestionnairesAppropriate situations: when views of large numbers of people needto be obtained when staff of organization are geographicallydispersed for systems that will be used by the generalpublic and a profile of the users is required 32. 32QuestionnairesRequire skill to design effectively (SeeBox 6.2 for guidelines) 33. 33User InvolvementA variety of stakeholders: senior managementwith overallresponsibility for the organization financial managerswho control budgets managers of user departments representatives of users of the system 34. 34User InvolvementDifferent roles: subjects of interviews representatives on project committees evaluators of prototypes testers as trainees on courses end-users of new system 35. Documenting Requirements Documentation should follow organizationalstandards CASE tools that produce UML models maintainassociated data in a repository Some documents will need separate storage ina filing system: interview notes copies of existing documents minutes of meetings details of requirements35 36. Documenting RequirementsDocuments should be kept in adocument management system withversion controlUse use cases to document functionalrequirementsMaintain a separate requirements listReview requirements to exclude thosethat are not part of the current project36 37. Requirements37ListUse Case ModelCandidateRequirementsRequirementsAnalystElicitrequirementsProject InitiationDocumentSelectrequirementsDevelopuse casesGlossary 38. Use Case Model38RequirementsTeamRequirementscapture and modellingProject InitiationDocumentRequirementsListInterfacePrototypesInitial SystemArchitectureGlossary 39. SummaryIn this lecture you have learned about:The distinction between the current andrequired systemsWhen and how to apply the main factfinding techniquesThe roles played by usersThe need to document requirements39