ZEIT2301 Design of Information Systems Requirements Gathering Week 03:Requirements Determination ZEIT2301 Design of Information Systems Requirements Gathering School of Engineering and Information Technology UNSW@ADFA Dr Kathryn Merrick Session 2, 2010

Week 03: Requirements Determination ZEIT2301 Design of Information Systems Week 03:Requirements Determination 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 Session 2, 2010

Analysis phase of the SDLC ZEIT2301 Design of Information Systems Week 03:Requirements Determination 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 Session 2, 2010

Analysis: What is the problem? ZEIT2301 Design of Information Systems Week 03:Requirements Determination 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. Session 2, 2010

Requirements Determination ZEIT2301 Design of Information Systems Week 03:Requirements Determination 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 Session 2, 2010

Functional and Non-Functional Requirements ZEIT2301 Design of Information Systems Week 03:Requirements Determination 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 Session 2, 2010

Non-Functional Requirements ZEIT2301 Design of Information Systems Week 03:Requirements Determination Non-Functional Requirements Requirement type Example Operational The system should be able to fit in a pocket or purse The system should be able to integrate with the existing inventory system. Performance Any interaction between the user and the system should not exceed 2 seconds. The system should receive updated inventory information every 15 minutes. Security Only direct managers can see personnel records of staff Customers can see their order history only during business hours. Cultural & Political The system should be able to distinguish between United States and European currency The system shall comply with insurance industry standards. Session 2, 2010

Criteria for quality requirements ZEIT2301 Design of Information Systems Week 03:Requirements Determination Criteria for quality requirements Correct Unambiguous Complete Consistent Verifiable Modifiable Traceable Ranked for importance Source: IEEE Standard 830-1998: IEEE Recommended Practice For Software Requirements Specifications Session 2, 2010 9

ZEIT2301 Design of Information Systems Week 03:Requirements Determination 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. Session 2, 2010

ZEIT2301 Design of Information Systems Week 03:Requirements Determination A bad requirement “Provide a means to transport a single individual from home to place of work”. Management Interpretation I T User Ambiguous Session 2, 2010

Prioritising Requirements ZEIT2301 Design of Information Systems Week 03:Requirements Determination 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” Session 2, 2010

Requirements Analysis Strategies ZEIT2301 Design of Information Systems Week 03:Requirements Determination Requirements Analysis Strategies The basic process of requirements analysis 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 Session 2, 2010

1. Business Process Automation ZEIT2301 Design of Information Systems Week 03:Requirements Determination 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 Session 2, 2010

2. Business Process Improvement ZEIT2301 Design of Information Systems Week 03:Requirements Determination 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 Session 2, 2010

3. Business Process Reengineering ZEIT2301 Design of Information Systems Week 03:Requirements Determination 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 Session 2, 2010

Selecting the Appropriate Strategies ZEIT2301 Design of Information Systems Week 03:Requirements Determination Selecting the Appropriate Strategies Business Process Automation Business Process Improvement Business Process Reengineering Potential benefit Low–moderate Moderate High Project cost Low Breadth of analysis Narrow Narrow-moderate Very broad Risk Very high Session 2, 2010

Determining Requirements ZEIT2301 Design of Information Systems Week 03:Requirements Determination 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 Session 2, 2010

ZEIT2301 Design of Information Systems Week 03:Requirements Determination 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 Session 2, 2010

Interviewing Strategies ZEIT2301 Design of Information Systems Week 03:Requirements Determination Interviewing Strategies Top-down How can order processing be improved? High-level: Very general Medium-level: Moderately specific How can we reduce the number of times that customers return ordered items? Low-level: Very specific How can we reduce the number of errors in order processing (e.g., shipping the wrong products)? Bottom-up Session 2, 2010

ZEIT2301 Design of Information Systems Week 03:Requirements Determination Types of Questions 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? Session 2, 2010

ZEIT2301 Design of Information Systems Week 03:Requirements Determination 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 Session 2, 2010

Good Questionnaire Design ZEIT2301 Design of Information Systems Week 03:Requirements Determination 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 Session 2, 2010

ZEIT2301 Design of Information Systems Week 03:Requirements Determination 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 Session 2, 2010

ZEIT2301 Design of Information Systems Week 03:Requirements Determination 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 Session 2, 2010

5. Joint Application Development ZEIT2301 Design of Information Systems Week 03:Requirements Determination 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 Session 2, 2010

ZEIT2301 Design of Information Systems Week 03:Requirements Determination JAD Meeting Room JPEG Figure 5-5 Goes Here Session 2, 2010

ZEIT2301 Design of Information Systems Week 03:Requirements Determination 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 Session 2, 2010

Managing Problems in JAD Sessions ZEIT2301 Design of Information Systems Week 03:Requirements Determination 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 Session 2, 2010

Selecting Appropriate Techniques ZEIT2301 Design of Information Systems Week 03:Requirements Determination Selecting Appropriate Techniques Interview JAD Question-naires Document Analysis Observation Type of information As-is, improves, to-be As-is, improves As-is Depth of info High Medium Low Breadth of info Info integration User involvement Cost Low-medium As-is : understanding current system Improves: identifies improvements To-be: developing the new system Session 2, 2010

6. Prototyping in the Requirements phase ZEIT2301 Design of Information Systems Week 03:Requirements Determination 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. Session 2, 2010

ZEIT2301 Design of Information Systems Week 03:Requirements Determination 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 Session 2, 2010

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