REQUIREMENTS PLANNING AND ELICITATION

Modules/Module3/Mod3Home.html

Module 3 - Home

Requirements Planning and Elicitation

Modular Learning Outcomes

Upon successful completion of this module, the student will be able to satisfy the following outcomes:

• Case
  • Explain why it is necessary to elicit requirements from users and the role requirements play in the lifecycle. 
  • Identify the characteristic that make individual requirements good or bad.
• SLP
  • Describe the type of requirements that should be included in a requirements document.
• Discussion
  • Analyze IT organizations, requirements and lifecycle issues with colleagues.

Module Overview

It is very challenging to make sure that everyone sees a common vision of the things they are trying to produce in a project. It is difficult to find out what stakeholders want, then figuring out from what they say they want, to what they actually need. It is also difficult to write it well and keep it up to date. One key piece is to determine if the project team has the right information from the gathering and elicitation steps. After careful reviews and information validation, the business analyst can begin writing the requirements that actually represent the project solution. While it sounds really straight forward, it is remarkably difficult to do it well in one try. The two key components of writing requirements include gathering the correct information and second making sense of that information and translating it into workable requirements with measurable deliverables.

There are several reasons why requirements can be problematic. Experts in requirements practices agree that the sources that lead to requirements’ errors include incorrect facts being offered by the customer, followed by omission, then inconsistency, ambiguity, and finally misplaced requirements. Many of the theories and concepts of gathering requirements are not difficult to understand. What is difficult is implementing them in various environments. For example, the project team could use ineffective techniques to gather requirements or run requirements in isolation. Also, the requirements provided by the stakeholders are often incomplete because some people have difficulty thinking in terms of business functions. Similarly, stakeholders may not be willing to commit time to helping the project team gather and document their requirements or build a picture of what they want to say. Other issues include a lack of joint responsibility between the project team and stakeholders.

Requirements and Standards

Similar to the organizations discussed in Module 2 for stakeholders, there is also guidance on requirement standards through the Institute of Electrical and Electronics Engineers (IEEE), Project Management Institute (PMI), and the International Institute of Business Analysis BABOK handbook. These organizations address strategic business requirements, feasibility, user capabilities and system characteristics, as well as technical design requirements. The guidance, advice, and templates found at these organizations can translate into any industry software development project. To handle requirements planning effectively, the project team needs to take a holistic view of a project and understand how it relates to the larger organization. For instance BABOK (2015), describes six knowledge areas and sequence of activities as follows.

The first knowledge area is about identifying key stakeholders, selecting appropriate business analysis techniques, and defining the process for managing requirements.

The second knowledge area or the elicitation process addresses gathering and collecting requirements from the stakeholders about the solution and the transition. Typical activities include identifying stakeholder needs and concerns, describing the organizational environment, defining methods for gathering requirements, and ensuring requirements are complete, clear, correct and consistent.

The third knowledge area includes enterprise analysis, providing context and understanding of the organization. Typical activities include identifying, refining and clarifying business needs, defining solution scope, performing problem definition and analysis, developing the business case, and building feasibility studies.

The fourth knowledge area includes the requirements analysis about progressively elaborating stakeholder and solution requirements. Typical activities here include, prioritizing solution requirements, analyzing, structuring and specifying stakeholder needs, defining solutions that meet stakeholder needs and verifying, and validating the resulting requirements.

The fifth knowledge area provides the solution and validation to ensure that stakeholder meet objectives. This area should be thoroughly tested and smoothly implemented and should occur after the solution design is agreed upon. Typical activities include, evaluating proposed solutions to determine the best fit, identifying gaps and shortcomings in proposed solutions, determining workarounds and changes to the solution and assessing project success after solution deployment.

The sixth knowledge area oversees management and communication and ensures that stakeholders and the project team remain in agreement on the solution's scope. This occurs across the project life cycle. This area builds maturity, repeatability, and clarity into a methodology of recognized standards. Typical activities include, managing conflicts, issues and changes, and deciding when and where requirements communication need to occur.

Requirements Analysis

Once the project team has gathered enough information during elicitation, they need to do something with it. Table 3-1 shows the various ways to elicit requirements information. Requirements’ review may open up a lot of questions such as figuring out the capabilities required, the hardware, software, and processes as well as reporting mechanisms.

Table 3-1 Requirements Elicitation

Requirements Elicitation Techniques

Stakeholder analysis Analysis of existing systems and documentation Reading of background materials Task observation Questionnaires Interviews Brain storming Join Application Development (JAD) Prototyping Use case and scenarios

Source: Richards (2017)

The analyst will want to continue asking questions during the analysis process, until all have a clear understanding of the detailed level. The requirements document must contain all aspects gathered during the meetings and how they will be delivered. Table 3-2 explains how requirements gathering techniques can be analyzed in terms of data application.

Table 3-2 Requirements Gathering and Application

Source: Peersman (2014)

While eliciting the information, the analyst would want to consider what level the information stakeholders are providing. Is it high-level concepts, or detailed information, and based on the scope of the project where these pieces of information fit in? During the elicitation process the analyst may already have a sense of the buckets or categories the analyst is going to put elicited information in such as functional, data, or performance categories. Table 3-3 illustrates how to identify requirement types and how these requirements can be classified in the requirements documents addressing the business, technical, and organizational purposes. Using this approach is critical to successful requirements management.

Table 3-3 Requirements Classification
Functional requirements	Performance requirements
The functional requirements are the real essence of a requirements specification. Functional requirements are characterized by verbs that perform actions. They state what the system should do. Examples are: - The system will display the titles of all the books written by the specified author. - The system will continuously display the temperatures of all the machines.	These are measures of performance, some of which are quantitative, and some of which can be used as part of testing. Examples are: _ cost _ delivery date _ response times (e.g. the system will respond to user requests within one second.) _ data volumes (e.g. the system must be able to store information on 10,000 employees.) _ loading levels to be coped with (e.g. the system must be able to cope with 100 transactions per minute from the point-of-sale terminals). _ reliability requirements (e.g. the system must have a mean time between failure of six months.) _ security requirements (e.g. use of anti-virus, password protection)
Data requirements
Data requirements have three components: 1. users’ data that is input to or output from the system via screen, keyboard or mouse. 2. data that is stored within the system, usually in files on disk, for example, information about the books held in a public library. 3. information passed to or from another computer system, for example, to a server.

Source: Richards (2017)

The project team must consider that requirement categories may work in the beginning, but then decide later to restructure them differently based on elaboration or iteration. In elicitation, the analyst is gathering information, and in analysis he/she is making sense of it. In elicitation the analyst is receiving from the stakeholders the stated requirements and the things they say are needed. During analysis, the requirements are analyzed for implementing a solution. Those are the two pieces to review back and forth, analyze some, do a little modeling, take a look, and discover new knowledge is possible. At some point, documenting or specifying the requirements will start to come into the process once the analysts has enough information to start to write. Documenting can be done in many ways including text, matrices, diagrams or models. If the organization has a strong methodology, templates, and processes are well-defined, the writing process may go smooth. Working from the output template backwards to elicitation and analysis would help drive consistency and high-quality within the writing and presentation effort. Assumptions and constraints must also be considered in requirements to ensure the limits and what is outside the project scope. There are many requirements management programs in the market, and if the organization is planning to buy one, the project team can help research the best option for internal use. 

Privacy Policy | Contact