Failed requirements are one of the most common reasons of failed projects. In fact, the more of requirements are missed, the more expensive it is for organisations . EDEL Technology Consulting uses numerous methods to ensure that you as client never lose money because of incomplete requirements
The requirement gathering techniques may differ from one project to another. Some requirement gathering techniques may prove highly beneficial for you in one project but may not be as productive in the other project or for some other company. Therefore the usefulness of a technique is determined by its need and the kind of advantages it offers in a particular project. There are 10 essential requirement gathering techniques that you must be aware of in order to manage the projects in a better way and run your business successfully are:
- Brainstorming
- Document Analysis
- Domain Analysis
- Interface Analysis
- Interview
- Observation
- Prototyping
- Requirements Workshop
- Reverse Engineering
- Survey
We discuss some of them below
Interviews
Interviews are strong medium to collect requirements. Organization may conduct several types of interviews such as:
- Structured (closed) interviews, where every single information to gather is decided in advance, they follow pattern and matter of discussion firmly.
- Non-structured (open) interviews, where information to gather is not decided in advance, more flexible and less biased.
- Oral interviews
- Written interviews
- One-to-one interviews which are held between two persons across the table.
- Group interviews which are held between groups of participants. They help to uncover any missing requirement as numerous people are involved.
Surveys
Organization may conduct surveys among various stakeholders by querying about their expectation and requirements from the upcoming system.
Questionnaires
A document with pre-defined set of objective questions and respective options is handed over to all stakeholders to answer, which are collected and compiled.
A shortcoming of this technique is, if an option for some issue is not mentioned in the questionnaire, the issue might be left unattended.
Task analysis
Team of engineers and developers may analyze the operation for which the new system is required. If the client already has some software to perform certain operation, it is studied and requirements of proposed system are collected.
Domain Analysis
Every software falls into some domain category. The expert people in the domain can be a great help to analyze general and specific requirements.
Brainstorming
An informal debate is held among various stakeholders and all their inputs are recorded for further requirements analysis.
Prototyping
Prototyping is building user interface without adding detail functionality for user to interpret the features of intended software product. It helps giving better idea of requirements. If there is no software installed at client’s end for developer’s reference and the client is not aware of its own requirements, the developer creates a prototype based on initially mentioned requirements. The prototype is shown to the client and the feedback is noted. The client feedback serves as an input for requirement gathering.
Observation
Team of experts visit the client’s organization or workplace. They observe the actual working of the existing installed systems. They observe the workflow at client’s end and how execution problems are dealt. The team itself draws some conclusions which aid to form requirements expected from the software.
Prototyping
Prototypes can be very effective at gathering feedback. Low fidelity prototypes can be used as an active listening tool. Often, when people can not articulate a particular need in the abstract, they can quickly assess if a design approach would address the need. Prototypes are most efficiently done with quick sketches of interfaces and storyboards. Prototypes are even being used as the “official requirements” in some situations.
Software Requirements Characteristics
Gathering software requirements is the foundation of the entire software development project. Hence they must be clear, correct and well-defined.
A complete Software Requirement Specifications must be:
- Clear
- Correct
- Consistent
- Coherent
- Comprehensible
- Modifiable
- Verifiable
- Prioritized
- Unambiguous
- Traceable
- Credible source
Credits
http://mobidev.biz/
http://tynerblain.com/