4: Requirements Determination

Introduction

The planning phase's deliverable is the System Request; the analysis phase takes the general ideas outlined in the system request and refines them into a detailed system requirements definition (Ch4), use cases (Ch5), process models (Ch6) and a data model (Ch7) that together form the System Proposal. The system proposal also includes revised deliverables from the previous phase (Analysis) such as the feasibility analysis (Ch2) and the work plan (Ch3).

Importance of the requirements determination step: ...several studies have shown that more than half of all system failures are due to problems with the requirements.

Requirement Determination

The purpose of the requirement determination step is to turn the very high-level explanation of the business requirements stated in the System Request into a more precise list of requirements that can be used as input to the rest of the analysis phase (creating use cases, building process models, and building a data model), which further require and expand on the requirements and ultimately lead to design.

Requirement: A statement of what the system must do or what characteristic it needs to have.

At the analysis phase, the requirements are written from the perspective of the businessperson or user, focus on "what"--and are called business-- or user requirements. In contract, the requirement in the design phase are written from the perspective of the developer (and hence, are more technical), focus on "how" [the system will be implemented], and are called system requirements.

Requirements: Functional and Nonfunctional

A functional requirement relates directly to a process the system has to perform or information it needs to contain; they define the functions that the system needs to have. (E.g.: search facility)

Nonfunctional requirements refer to behavioral properties that the system must have, such as performance and usability. (E.g.: the ability to access the system via a Web browser.) Nonfunctional requirements are general pertinent to user interface, hardware and software, and the systems underlying architecture.

The following are different kinds of nonfunctional requirements. Note that they do not describe the business processes or information, but are important in understanding what the final system should be like.

• Operational nonfunctional requirements: The physical and technical environment in which the system will operate
• Performance nonfunctional requirements: The speed, capacity, and reliability of the system
• Security nonfunctional requirements: Who has authorized access to the system under what circumstances
• Cultural and political nonfunctional requirements: Cultural, political factors and legal requirements that affect the system

Requirement Definition (Report): a straightforward text report that lists the functional and nonfunctional requirements in an outline format. (Sometimes, the list items are prioritize as having "high," "medium," or "low" importance in the new system...

Determining Requirements

Three kinds of techniques have become popular to help analysts and businesspeople work together to determine the business requirements (i.e. to examine the as-is system, identify exactly what needs to change, and develop a concept for the to-be system). They are tools that analysts can use when the need to guide the user in explaining what is wanted from a system:

Business Process Automation (BPA)

• creates a small amount of change that improve process efficiency
• leaving the basic way in which the organization operates unchanged, and using computer technology to do some of the work
• two techniques:
  • Problem Analysis: asking users and managers to identify problems with the as-is system and to describe how to solve them in the to-be system.
  • Root Case Analysis: (Rationale: Often enough, in attempting to address a problem, we address the symptom of the problem, not the true problem or the root cause, itself.) Root cause analysis focuses on problems, not solutions

Business Process Improvement (BPI)

• creates a moderate amount of change to take advantage of new opportunities offered by technology or to copy what competitors are doing
• can improve efficiency (doing things right) and effectiveness (doing the right things)
• activities in BPI include duration analysis, activity-based costing, and information bench-marking:
  • Duration Analysis: detailed examination of the amount of time it takes to perform each process (and subprocess) in the as-is system in comparison to the total amount of time it takes, on average, to complete the entire operation. When there is a significant difference between the two, the process(es) might be in need of an overhaul. This inefficiency might likely occur because the process is badly fragmented; processes in which many different people work on small parts of the inputs are prime candidates for process integration or parallelization.
  • Activity-Based Costing: examines the cost of each major process or step in a business process rather than the time taken, identify the most costly processes, and focus improvement efforts on them. Essentially, we examine the direct cost of labor and materials for each input as well as indirect costs such as rent, depreciation, utilities, etc.
  • Informal Benchmarking: (Benchmarking refers to studying how other organizations perform a business in order to learn how one's organization can do some thing better.) Informal benchmarking is fairly common for "customer-facing" business processes (i.e. those processes that involve interaction with the customer) and involves thinking about other organizations or visiting them as customers to see how the business process is performed.

Business Process Reengineering (BPR)

• creates a significant amount of change that affects the whole organization
• changing the fundamental way in which the organization operates--"obliterating" the current way of doing business and making minor changes to take advantage of new ideas and new technology.
• Outcome analysis, technology analysis, and activity elimination are three popular BPR activities
  • Outcome Analysis: focuses on understanding the fundamental outcomes that provide value to customers; it involves determining customers' real needs: thinking carefully about what the organization's products and services enable the customer to do--and what they could enable the customer to do.
  • Technology Analysis: identifying a list of relevant technologies and then systematically identifying how each could be applied to the business process and how the business could benefit from it
  • Activity Elimination: identifying how the organization could eliminate each and every activity in the business process, how the function could operate without it, and what effects are likely to occur.

Selecting the Appropriate Technique

Potential Business Value

• As BPA does not seek to change the business processes, it can only improve their efficiency;
• BPI usually offers moderate potential benefits; it can increase both efficiency and effectiveness;
• BPR creates large potential benefits because it seeks to radically improve the nature of the business

Project Cost

• In general, BPA requires the lowest cost
• BPI can be moderately expensive
• BPR is usually expensive

Breath of Analysis

• BPA typically analyzes a single process
• BPI usually includes several business functions
• BPR often spans several major business processes

Risk of Failure

• BPA: low to moderate
• BPI: low to moderate
• BPR: very high

Requirements Analysis Techniques

The basic process of analysis is divided into three steps:

1. understanding the as-is system
2. identifying improvements
3. developing requirements for the to-be system

Requirements Gathering Techniques

1. Interviews

5 Steps:

1. selecting interviewees (create interview schedule)
2. designing interview questions (close-ended, open-ended, and probing questions; approaches: top-down [general to specific], bottom-up [specific to general])
3. preparing for the interview
4. conducting the interview
5. post-interview follow-up (prepare interview report--advisedly within 48 hours of the interview; send copy to interviewee for his/her perusal and/or clarification, if needed)

2. Joint Application Development (JAD)

• an information gathering technique that allows the project team, users, and management to work together to identify requirements for the system
• a structured process in which 10 to 20 users meet together under the direction of a facilitator skilled in JAD techniques (the facilitator sets the meeting agenda and guides the discussion, but does not join the discussion as a participant)
• shortcomings: people are sometimes reluctant to challenge the opinions of others (particularly their superiors); a few people dominate the discussion and not everyone participates. e-JAD attempts to address these shortcomings by using groupware
• Steps
  1. selecting participants
  2. designing the JAD session
  3. preparing for the JAD session
  4. conducting the JAD session: the facilitator must perform three key functions: 1. ensure that the group sticks to the agenda; 2. help the group understand the technical terms and jargons that surround the system development process and help the participants understand the specific analysis techniques used; 3. record the group's input on a public display area (a whiteboard, flip chart, projector, etc) *The facilitator must never inject his/her opinion into the discussion and must remain neutral at all times
  5. post JAD follow-up: prepare post-session report and circulate among session attendees; the post-session report usually takes about a week or two after the JAD session to complete (as it is longer and provides more information than the interview report)

3. Questionnaires

paper, electronic (via e-mail or Web-based)

Steps:

1. selecting participants: (representative) sample of population; realize that not everyone who receives a questionnaire will complete it
2. designing the questionnaire: questions should be clear and leave no room for misunderstanding--use close-ended questions; key issue: having a clear understanding of how the information collected from the questionnaire will be analyzed and used.
3. administering the questionnaire
4. questionnaire follow-up

4. Document Analysis

• reviewing documentation (including system documentation, user manuals, forms, reports, policy manuals, etc.) to understand the as-is system

5. Observation

• observation is a good way to check the validity of information gathered from indirect sources such as interviews and questionnaires.
• the analyst's task if to keep a low profile, to not interrupt those working, and to not influence those being observed (of course, people tend to be extremely careful in their behavior when they are being watched, so the analyst may not observe normal day-to-day routine)
• observation is generally used to supplement (i.e. support or question information contained in) interviews and questionnaires.

Selecting the Appropriate Techniques

Each of the requirements gathering techniques has strengths and weaknesses--no one technique is always better than the others, and in practice most most project use a combination of techniques. In any case, the following criteria are pertinent to selecting the appropriate requirements gathering technique:

• Type of Information
• Depth of Information
• Breadth of Information
• Integrity of Information
• User Involvement
• Cost
• Combining Techniques

Case Study: Applying the Concepts at CD Selections. p. 132, Dennis & Wixom.