In the previous blog post, I discussed a critical consideration in the Requirements Challenge: Knowing the Unknown, as well as a powerful technique to model customer satisfaction and expectations called the Kano Model. In this blog, we will consider the following question: Are all perspectives of the requirements captured in order to achieve consensus and common understanding?
Representing all sides
Requirements themselves can take many forms, among them include:
- Traditional “shall” statements written in natural language, à la IEEE 610 and IEEE 29148
- Ivar Jacobsonian Use Cases
- UML diagrams, e.g., State diagram, Class diagram, Activity diagram
- User stories, typically written in a succinct format, e.g., “as a <user> I want to <perform some action> so that <some measurable value can be attained>”.
- Acceptance criteria, which often accompany a user story, e.g., the Gherkin format of “given <context>, when <event>, then <expected behavior/result>”
- Test strategies, plans, and results
- Defect or bug descriptions
- Existing constraints, such as operational conditions, IT architecture and interfaces to adjacent systems; or even organizational constraints/mandates
- Norms and standards from regulatory authorities such as HIPAA, SOX, FAR/DFARS, UL, GDPR etc.
- An email, verbal conversation, or scratch paper/napkin
More to the last point, a common misconception in the Agile framework is that requirements (and documentation in general) is not needed, since the manifesto plainly states that working software is more highly valued. Instead, Agile teams are encouraged to find the simplest solution when it comes to JIT documentation and complying with applicable regulations – while still focusing on delivering working increments of the product or service. On a tiny Agile team with few customers, no regulations and universally-understood product requirements, perhaps napkins as an RM tool is sufficient; while others will have to leverage tools like JIRA and VersionOne to manage requirements, releases, and test cycles.
Regardless of the product, service and development methodology at hand, three distinct types of needs must be considered: business, functional, and technical needs. Business needs derive from the purchasing authority of the system or product, functional from the end users or customers, and technical from the constraints and qualities of the product or system itself, including underlying technologies. Because the users of complex systems typically differ from the purchasers, and because IT department must abide by certain security and architectural standards, these needs can often come in conflict with one another. However, by involving the correct stakeholders and representatives from these three areas early – prior to product development – such conflicts can be avoided or resolved without sacrificing product quality or project schedule.
Next Up: The Requirements Challenge: Requirements Quality (Part 3 of 3)
Cody May is Principal Business Analyst at SQS USA.
