After you determine the business need and applicable stakeholders, the next step is identify the requirements. This stage is called requirements discovery.
A good discovery process is critical for any project. The requirements that are generated at this stage form the backbone of the entire system or process, setting it up for success or failure.
What is a Requirement?
- A requirement is something that is needed or wanted with regards to a future system, product, process or procedure.
- Effective requirements define a project’s real needs as well as the effective, clear solutions
- A solution may require multiple Requirement Levels and Types
Why Are Requirements Important?
- Vague or missing requirement specification is one of the highest causes of project failure.
- If the requirements are insufficient (i.e., not clearly and comprehensively defined), the project may be considered a failure even if it is delivered on time and within budget.
- Without well-defined requirements prior to vendor selection, your team may become overwhelmed and “charmed” by the sales pitch and select a SaaS or OTS product that will not meet their actual needs.
- Some of the most common reasons for insufficient requirements are:
- Incomplete list of stakeholders
- Poor stakeholder representation/support
- Time/schedule limitations
- Limited knowledge/understanding of the business analysis process
1. Elicitation
- Elicitation is how information is obtained from the stakeholders to discover the requirements for the solution. It typically involves talking with stakeholders directly, researching topics, and reviewing existing documentation.
- You can elicit requirements via any method that enables you to uncover detailed information related to the project. Some of the most common requirements elicitation techniques include:
- Brainstorming
- Document Analysis (reviewing existing documentation)
- Focus Groups
- Interface Analysis (reviewing existing interfaces)
- Interviews
- Observation
- Wireframing or Prototyping
- Workshops
- The project’s stakeholders, complexity and timeline will dictate the best method or combination of methods for eliciting requirements.
2. Documentation
- The goal of requirements documentation, or specification, is to state each need of the proposed system or process (who, what, where, when and why) precisely and thoroughly.
- Requirements must also eliminate ambiguity. For example, “The software system will time out when the customer leaves their computer for a while,” is a poor requirement. “The system will time out after 60 minutes of inactivity,” is better.
- Your project characteristics will influence the method that will work best, but a few of the more popular options include:
- Requirements Specifications
- Diagrams
- User Stories
- Use Cases
- Wireframes
- Prototypes
3. Review
- After you define your requirements, you must effectively communicate them to necessary stakeholders to provide them with an opportunity to express feedback, request adjustments, and agree or provide approvals.
- Once these stakeholders have signed off on the requirements, the RFP (Request for Proposal) or system development process can begin.
- Communicating information does not simply involve pushing information out and assuming it was received and understood. The method of delivering the information may need to change if the stakeholders are not receiving or understanding it. Multiple forms of communication might be required for the same information, though reviews are best executed during group or individual collaboration meetings.