The first thing people need to do regarding non/functional requirements and or technical design constraints (or guidance) is to admit that they have them. We all have them, it’s OK and the one thing I’ve learned over time is that there’s not one absolute right way to deal with them, but there is certainly one wrong way to deal with them – not dealing with them at all until they are discovered by the customer.
So before we move any further, let’s be clear on what we are talking about here. Non/functional requirements and or technical design constraints are things like:
- Needs to be compliant with Web Accessibility Standards
- Solution must be PCI compliant
- Screens need to adhere to Design X (as we all decided)
- All error messages should be clear and human readable (not in Klingon)
- Application should prevent Users from performing data destruction actions
OK, before everyone says, “these are backlog items!” Well, they can be and at times these may be tasks – and in most cases, these types of items are part of the acceptance criteria (a.k.a. What does it mean to be done?). In some circles, these may be captured as technical stories and in those same circles the phrase "technical stories" is not allowed to be spoken.
In the general sense, there’s multiple ways to manage these non/functional requirements and one of the most constructive discussion threads out there in the blogosphere is by Mike Cohn – Non/Functional Requirements as User Stories
. There are a few points to glean from the blog and the comments that ensued:
- Post in the team rooms the design constraints and or development parameters (remember development includes coding and testing). These are things that everyone should keep top/of/mind when designing, constructing, and validating functionality. I would recommend doing this no matter how you use VersionOne.
- There are multiple good solutions and the best solution for you may vary based on the nature of your product or your team composition.
- Nobody involved in the discussion was or is using VersionOne, because VersionOne would help with all approaches discussed (at least that’s my opinion ?).
So here are a few scenarios and usages of VersionOne you can leverage:
to define tasks and tests surrounding design constraints. For example, being compliant with Web Accessibility Standards varies based on the site and or application. So you can create a Story template called “Web Accessibility Standards Compliance (WCAG 2.0)” and add Acceptance Tests for each of the requirements (e.g. ”Perceivable – Provide Text Alternatives for any non/text content”, “Perceivable – Provide Alternatives for time/based media”). Now, when planning your iterations/sprints and using the Plan Backlog Item screen, you can copy the applicable Acceptance Tests to the story being planned. This makes it very explicit to the team members that these design constraints are applicable to the story.
to capture each of the design constraints, when a story falls out of compliance – usually discovered through testing or discussion – then block that story with the appropriate design constraint issue. This is a very explicit way to expose the constraints – especially for remote teams. You can use the “Issue Type” field to define those Issues that are design constraints. If the design constraint Issues are defined at a top/level of your project tree, then you’ll be able to view all Backlog Items (Stories and Defects) that may be out of compliance across multiple projects.
If you are using VersionOne’s Ultimate Edition, you can leverage the Regression Testing
capabilities. This will allow you to create a Test Set to manage compliance per release or at periodic check points. The idea is that with the Regression Testing, you can have a set of Acceptance Tests (assuming there are many test/validation points surrounding the design constraints) and every so often (e.g. every third iteration) create a Test Set to have a team member validate that compliance with the design constraints are being met. This method is not as explicit as adding the Acceptance Tests directly to the stories, but it reflects the work involved in validating and should raise backlog items to address compliance.
You may find that a combination of methods works well for your teams. One thing is for certain, Non/functional requirements need to be recognized and visible. Tracking these in VersionOne can be easy. Using VersionOne to track non/functional requirements and technical design constraints can ensure quality and audit/ability.
Are you using VersionOne for non/functional requirements and or technical design constraints? If so, please comment and share your experiences.