SpiraTeam v4.1 introduced a new feature allowing you to create requirement workflows. This feature allows you to create a workflow that models your signoff process. The question that begs is - what should my requirements signoff process look like...
If you took a journalism class in high school, or college, then you are aware of the Who, What, Where, When, Why, and How. Sometimes referred to as the 5 W's. Yes, I know there are 6 questions, and that one starts with an H, but the 5W's and 1 H doesn’t sound as good. That is just the way it is.
What does this have to do with sign offs, well it defines the primary questions that will determine your flow and what happens to get signoff:
- Who - Looking at your organization structure, there is typically an individual who is responsible for the specification? This individual, or one with equivalent knowledge of the intent, must be the person to "sign off" - agreeing to the fact that the requirement, as documented, meets or exceeds the intention of the specification. Another definition to keep in mind is that this is the stakeholder. Short answer, this person needs to carry the weight and authority to say yes.
- What - What are the expectations? Not necessarily the entire specification, but a part of the specification that is meaningful and cohesive. What we are working on? Several requirements may make up a specification and will provide the entire picture. Often this is organized using the SpiraTeam nesting feature for requirements where several smaller parts of the specification may roll up into the specification as a whole.
- Where - In a review. This can be a sit down session, or a virtual notification. With appropriate workflow the signer will be notified that it time for a review, but the department or process you use may point you in a direction that requires a formal meeting.
- When - Tricky question. When can be difficult when many parts intersect on a specification. Do you wait for the whole specification to be covered before review, or do you have individual pieces signed-off as they are prepared? perhaps by using workflow, you can create a holding status that is a tentative approval until all the other pieces are ready, thereby providing a review and sign before the whole is complete, allowing you to address functional shortcomings before the whole is complete.
- Why - Why do we do sign off at all? This is the most important question. In medical sciences, signoff is a regulatory requirement, also in many financial institutions. But if you are a standard software shop, why do we go through this? You don’t have to, but I would recommend it, as a sign off on requirements removes some of the risk from delivering software. It prompts a conversation and inspection by the stakeholders which will percolate up any outstanding issues in usability or functionality.
- How - Starting on page 48 of the SpiraTeam Administration Guide there is a detailed look at requirement workflows. As with all workflows this workflow will insure the appropriate person is notified and provide specific documentation of the fact that a requirement has achieved signoff.
Do you use sign-off? How can we assist you in this area?