ZEIT2301 Design of Information Systems Requirements Gathering

1. ZEIT2301Design of Information SystemsRequirements Gathering School of Engineering and Information Technology UNSW@ADFA Dr Kathryn Merrick

2. Week 03: Requirements Determination • Become familiar with requirements analysis techniques. • To identify criteria for a “good” requirement • To review requirements gathering techniques • Ref: text Ch 4

4. Analysis phase of the SDLC • The System Request outlined the business need for a new system. • In the Analysis phase, the analyst needs to gain a more thorough understanding of the business problem domain and user requirements. • What exactly is the problem this system will address? • Output from this phase is a Requirements Definition Report and models which illustrate this required system functionality

5. Analysis: What is the problem? • In researching this question, the first challenge is finding the right people to question, interview or observe. • A stakeholder is a “person, group or organization that can affect (or be affected by) a new system.” (Dennis et al) • Identify particular user groups and how they will use the system. • The second challenge is collecting and integrating the information that has been obtained when researching the problem. • Mistakes made at this stage can negatively impact later phases. • Studies show that more than half of all system failures are due to problems with requirements.

6. Requirements Determination • Determining the precise requirements of the system - all capabilities and constraints • “A requirement is simply a statement of what the system must do or what characteristic it must have”. Dennis et al. • May change over time as the project moves from analysis to design to implementation • In the early stage of analysis, the emphasis is on business requirements – the “what” of the system • Later, in design, requirements become more technical – describe “how” the system will be implemented

7. Functional and Non-Functional Requirements • Functional requirements • Activities the system must perform • Based on procedures and business functions • Documented in analysis models • Eg: the library system must produce a report of overdue books • Non-functional (technical) requirements • Describes operating environment, performance objectives, security considerations, cultural factors • Documented in narrative descriptions of technical requirements • Eg: the system must have a web interface; must interface with existing inventory system, etc

8. Non-Functional Requirements

9. Criteria for quality requirements Correct Unambiguous Complete Consistent Verifiable Modifiable Traceable Ranked for importance

10. A Bad Requirement Software will not be loaded from unknown sources onto the system without first having the software tested and approved. • Ambiguous – if the software is tested and approved, can it be loaded from unknown sources? • (not) Testable – it is stated as a negative requirement making it difficult to verify. • (not) Traceable – a unique identifier is missing. 3.4.5.2 Software shall be loaded onto the operational system only after it has been tested and approved.

11. Management I T User Interpretation Interpretation Interpretation Ambiguous A bad requirement • “Provide a means to transport a single individual from home to place of work”.

12. Prioritising Requirements • MoSCoW Prioritisation • M - MUST have this. • S - SHOULD have this if at all possible. • C - COULD have this if it does not effect anything else. • W - WON'T have this time but would like in the future. • Managing change to avoid being overwhelmed by “requirements creep”

13. Requirements Analysis Strategies • The basic process of requirementsanalysis is divided into: • Understanding the existing (as-is) system • Identifying improvements • Developing requirements for the new (to-be) system • There are three strategies for requirements analysis • Business process automation • Business process improvement • Business process reengineering

14. 1. Business Process Automation • BPA leaves the basic way in which the organization operates unchanged and uses computer technology to do some of the work • Low risk, but low payoff • Planners in BPA projects invest significant time in understanding the current (as-is) system • Tends to solve problems rather than capitalize on opportunities • Improvements tend to be small and incremental Problem analysis

15. 2. Business Process Improvement • BPI makes moderate changes to the way in which the organization operates to take advantage of new opportunities offered by technology or to copy what competitors are doing • Typical approaches: • Duration analysis – examine how long it takes to complete each process • Activity-based costing – examine the cost of each minor process or step • Informal benchmarking – study how other organizations perform the process

16. 3. Business Process Reengineering • BPR changes the fundamental way in which the organization operates • Limited study of the current (as-is) system • goal is to focus on new ideas and new ways of doing business • Popular activities: • Outcome analysis: eg outcomes from the customer’s point of view • Technology analysis: technological opportunities • Activity elimination: eg get customer to enter the info via the web

17. Selecting the Appropriate Strategies

18. Determining Requirements • Requirements are best determined by systems analysts and business people together • Techniques available to the systems analyst: • Interviews • Questionnaires • Observation • Document analysis • Joint application development (JAD) • Throw-away prototyping

19. 1. Interviews • Selecting interviewees • Different perspectives: managers, users • Designing interview questions • unstructured (broad), structured (narrow) • Preparing for the interview • List questions, set priorities, schedule interview • Conducting the interview • Be professional, record info, give interviewee time to ask questions • Post-interview follow-up • Review notes, look for gaps

20. Interviewing Strategies Top-down How can order processing be improved? High-level: Very general How can we reduce the number of times that customers return ordered items? Medium-level: Moderately specific How can we reduce the number of errors in order processing (e.g., shipping the wrong products)? Low-level: Very specific Bottom-up

21. Types of Questions Examples Closed-Ended Questions * How many telephone orders are received per day? * How do customers place orders? * What additional information would you like the new system to provide? Open-Ended Questions * What do you think about the current system? * What are some of the problems you face on a daily basis? * How do you decide what types of marketing campaign to run? Probing Questions * Why? * Can you give me an example? * Can you explain that in a bit more detail? Types of Questions

22. 2. Questionnaires • Selecting participants • Using samples of the population • Designing the questionnaire • Careful question selection • Administering the questionnaire • Working to get good response rate • Questionnaire follow-up • Send results to participants

23. Good Questionnaire Design Begin with non-threatening and interesting questions Group items into logically coherent sections Do not put important items at the very end of the questionnaire Do not crowd a page with too many items Avoid abbreviations Avoid biased or suggestive items or terms Number questions to avoid confusion Pretest the questionnaire to identify confusing questions Provide anonymity to respondents

24. 3. Observation • Observation helps check validity of information gathered other ways • Users/managers, when asked, often don’t remember everything they do • But behaviours change when people are watched • Be careful not to ignore periodic activities • Weekly … Monthly … Annual

25. 4. Document Analysis • Review existing reports, forms, and procedure descriptions • Provides clues about existing “as-is” current system • Typical documents • Forms • Reports • Policy manuals • Look for user additions to forms • Look for unused form elements

26. 5. Joint Application Development • Allows project managers, users, and developers to work together • May reduce scope creep by 50% • Avoids requirements being too specific or too vague • Often the most useful method for collecting information from users

27. JAD Meeting Room JPEG Figure 5-5 Goes Here

28. The JAD Session • May involve several days over a period of a few weeks • Prepare questions as with interviews • Formal agenda and ground rules • Facilitator activities • Keep session on track • Help with technical terms and jargon • Record group input • Help resolve issues • Post-session follow-up • Key Roles • Facilitator • Scribe

29. Managing Problems in JAD Sessions • Reducing domination • Encouraging non-contributors • Avoid side discussions • Agenda merry-go-round • the same issue raised continually • Violent agreement • Inconsistent terminology masks potential agreement • Unresolved conflict • Help group select a better alternative • True conflict • Document as an open issue • Use humor

30. Selecting Appropriate Techniques As-is : understanding current system Improves: identifies improvements To-be: developing the new system

31. 6. Prototyping in the Requirements phase • In RAD (Rapid Application Development), an ultimate technique of the requirements phase is rapid prototyping of the solution • This assists in clarifying difficult requirements and helps avoid misunderstandings • Agile, XP (eXtreme programming) and phased development methodologies emphasise involving users and using prototyping to elicit requirements in an incremental fashion.

32. The System Proposal • The System Proposal is the result of the planning and analysis phases • The System Proposal typically includes: • Executive summary • System request • Work plan • Feasibility analysis • Requirements definition • Evolving system models

33. Summary • After today’s lecture you should be aware of: • Functional and non-functional requirements • Quality requirements • Techniques for gathering system requirements