Effective Techniques for Requirements Gathering

Speaking of development in Mexico, we can infer that many systems development projects, even projects in general such as ERP or CRM implementations, fails because they do not adequately define, specify, and manage the requirements.

Within this poor administration you can find factors such as little or no user participation, which can cause a poor definition of requirements, ambiguous or inaccurate requirements, coupled with this the poor management of the changes generated during the life of the project, which directly hits the duration of this and therefore to the planning. Resulting in customer dissatisfaction, extension of project duration or total project failure.

To achieve a successful software project you must understand the scope of the work to be done, the risks that can be incurred, the resources required, the tasks to be carried out, the effort (cost) to consume and the plan to follow. In order to obtain good requirements, we must first define what they are, what characterizes them and how they can be classified. There are many definitions of Requirement, I consider one of the most complete the following:

“A capability needed by a user to solve a problem or accomplish a goal”

Now that we can identify what is a requirement, the next thing is to see what are the characteristics that it must meet.

• Necessary. If you have any doubts about the need for the requirement, you can ask yourself “What would be the worst thing if you didn’t include it?” If no answer or any consequence is found, then it is not a necessary requirement.
  
• Complete. A requirement is complete if you do not need to expand details in your wording, that is, if sufficient information is provided for your understanding.
  
• Consistent. A requirement is consistent if it is not contradictory to another requirement
• Correct. Agreement between two parties. It contains only one idea.
  
• Feasible. The requirement must be fully feasible and within budget, schedule and other restrictions, if you have any doubt about its feasibility, you have to investigate, generate proofs of concept to know its complexity and feasibility, if still the requirement is not feasible you have to review the vision of the system and rethink the requirement.
  
• Modifiable. That some modification can be made to the requirement, and this is simple, consistent and complete.
  
• Prioritized. Categorizing the requirement helps us to know the degree of need for it Essential/Critical, Desired, Optional Verifiable.

• Verifiable. If a requirement cannot be verified, then how do you know if it was met or not? It must be possible to verify it either by inspection, test analysis or demonstration. When a requirement is written, the acceptance criteria must be determined.
  
• The specification must be organized in such a way that each function of the system can be traced back to its corresponding set of requirements. Facilitates design testing and validation.
  
• Sure. A requirement is concise if it is easy to read and understand, its wording should be simple and clear for those who will consult it in the future.

Now, the requirements can be grouped into a pyramid of types to be able to explain them:

Needs

Within the Pyramid of Requirements, located at the highest point, are the needs of the Stakeholders, they are oriented to business opportunities (problems) which must be covered satisfactorily. Some of these opportunities trigger the realization of a software system.

Characteristics (non-functional requirements)

Characteristics or Qualities that Stakeholders expect as part of the behavior of the Software system. Sometimes they are oriented to the “How” instead of the “What”. Features provide a lot of information about how the system should behave. They are related to the quality characteristics of the system:

Software Requirements (functional requirements)

 Software Requirements are the needs of the Stakeholders that require the System to comply satisfactorily. They are the ones that define the functions that the system will be able to perform, they describe the transformations that the system performs on the inputs to produce outputs. It is important to describe the What? and not the How?  These transformations must be com90pleted. These requirements as the software project progresses become the algorithms, logic, and much of the system code. Once we have identified the types of requirements that exist, and the characteristics that must be met, we can start with the description of the activities that will help us to make a good obtaining of requirements. We are not going to discover the black thread, the process is already more than defined, you just have to learn how to wear it properly. This set of activities is called Requirements Engineering, which plays a primary role in  the Software Development process, is what can support us to achieve successful projects, since it focuses on a fundamental area: the definition of what you want to produce. Its main task is to generate correct specifications that describe clearly, unambiguously, consistently and compactly, the behavior of the system. This process comprises five high-level activities:

1. Obtaining Requirements

This phase represents the beginning of each cycle. It is the most important part of the process since everything obtained in this phase will be the basis for the construction of the system. Here, requirements analysts will need to work alongside the customer to figure out the problem the system needs to solve. This is usually done in a joint called kick off, where the following must be specified:

• Objective of the system, and tentative dates of the start and end of the project
• Presentation of the Task Force
• Presentation or definition of stakeholders (involved in the definition of the requirements and functional leader, who is the one who authorizes the documents on behalf of the entire client team)
• Tentative dates of meetings with the client (Commonly used when it is a consultancy that provides customer service)

2. Requirements Analysis

It is the second step that Requirements Engineering dictates, involves refining, analyzing, and examining/scrutinizing the requirements obtained to ensure that all customers involved understand what they asked for, and to find errors, omissions and other deficiencies. At this stage, the requirements are read, conceptualized, investigated, ideas are exchanged with the rest of the team, problems are highlighted, alternatives and solutions are sought, and then meetings are set with the client to discuss the requirements. The activities to contemplate during this stage are:

• Reduce ambiguities in requirements. In this activity, the tasks that allow to eliminate the terms that have more than one meaning are carried out, unifying the lexicon used.
• Translate requirements into technical language. The requirements, already with less ambiguities, must be treated in order to bring them to a language that is approaching the technical language.
• Propose a logical model. A model of the problem must be built either in terms of flowcharts or any other type of representation that is considered convenient for modeling and that allows, in addition, to establish a link with the Specification Stage.

3. Requirements Specification

In this phase, the requirements agreed with the client are documented, at an appropriate level of detail. The complete description of the needs and functionalities of the system that will be developed is documented; It describes the scope of the system and how it will perform its functions, defining functional and non-functional requirements.

4. Requirements Verification

To do the verification it is recommended to first select several reviewers from different disciplines can be an analyst, architect, or even a SW engineer, but must be someone familiar with requirements engineering, in addition must have knowledge of the documentation standards of the organization. You can prepare a checklist for the review of the requirements, this will depend on the project that is being handled. What should be done is to make revisions to the document, apply desktop tests, etc. Here is an example of points to review in the documents obtained:

• Are all the functionalities required by the client included? (complete).
• Are there conflicts in the requirements? (consistency)
• Do any of the requirements have more than one interpretation? (unambiguous)
• Is each requirement clearly represented? (understandable)
• Can the requirements be implemented with the available technology and budget? (feasible)
• Is the specification written in appropriate language? (clear)
• Is it easy to make changes in requirements? (modifiable)
• Is the origin of each requirement clearly defined? (trackable)
• Can the Requirements be subjected to quantitative testing? (verifiable)

5. Acceptance of Requirements

This is a process where the analysts involved meet with the client and begin to give a formal review to the document, that is, they begin to read and explain each requirement, they can even rely again on paper prototypes to make the operation clearer, this so that everyone is in the same understanding of what will be done for each requirement. Once everyone agrees, the requirements specification is accepted/approved, a formal commitment is made that the Specification will be what is built and the client is asked for a formal approval via email or a signature on the physical document.

6. Requirements Management

Requirements management is done throughout the project, this involves keeping good control of changes, making sure to make the client see the impact on cost and / or delivery time of the project, but you must also take care of how these changes stick to the deliverables you have, according to the stage where they occur. Another important point is that you must make sure that all the activities of your project are given in time so as not to cause delays in delivery. It is recommended to take special care of the versions of documents (in a repository like Sharepoint) and code (in a tool like SourceSafe).

I am sure that following these lines, you will have a better result at the end of your development project.

If you prefer to receive professional help and avoid mistakes in financial and quality planning in your development project, I invite you to contact us.