Categories
Document Management Rapid JAD Requirements Software Development

Blow Your Mind Requirements For Results

Facebooktwittergoogle_plusredditpinterestlinkedinmail

The Magic 6 is a black ball with the number 6 on it

Six components of a well-written requirement are so powerful that I call them magical. Missing any one of these six requirement attributes will cost your project.

Capture them up front to save money, time, help communication, and minimize frustration. Have you hired a company to gather requirements? They should provide these six.

Because I love practical examples and keeping it simple I will provide a short explanation with a real life example. This example comes from a centralized system that tracks issues for a company with multiple locations.  

1. A Unique ID

This is the first attribute of a good requirement. In addition to being unique, the identifier for each requirement should capture an area or grouping as well as a count. The grouping communicates the area within the entire project and provides context. For a system that tracks and communicates issues, a View Updates group was created. The unique identifier, uses an abbreviation and a numeric. For this group I used VU.01 for the first requirement in the group View Updates.

2. Identification of who needs the requirement

This is typically a group name, such as Customer. This communicates the group needing the feature, which provides use context as well as an idea of security level. This system has customers who need to view issues affecting their multiple locations.

3. Statement of what is required

A statement of what is required identifies the task to be accomplished or the action to be performed. For customers with multiple locations, “Search by location is needed for issues.” This communicates an action a customer needs to take.

4. Statement of why the requirement is needed

The market for a product as well as competitor products can be the impetus for rapidly changing a requirement. Communicating why something is required also provides information on when it may no longer be needed. For issue tracking, search by a specific location is needed so that the customer can see all issues affecting a location.

5. Acceptance Criteria

Ideally acceptance criteria is communicated by a business owner. This provides clear communication to the development team when the business will agree that work on a requirement is fulfilled. When a customer can search by a specific location and all results are displayed, this requirement is complete. For more information on this topic, see The End Goal – Removing Ambiguity in Requirement

6. Business Owner

This identifies the person who can answer questions regarding a specific requirement, Matt Murdock. All requirements should have a point of contact in the business. It can be months after a requirement has been captured and development questions arise. In addition to clarification, there may be impacts from other events that come along and you will need to get input the right person in the business. 

Blow Your Mind

If you are looking at a requirements document and the Business Analyst captured all six of these attributes, that should blow your mind. Take them to lunch and thank them, they are going to save your project time and money.

Facebooktwittergoogle_plusredditpinterestlinkedinmail

By Greg Swearingen

Greg Swearingen’s been designing and building business applications for over 19 years and providing training for over 28. Applying his skill from the early days of Netscape Navigator to today's mobile environment he stays up on the best of the best. While having designed and developed numerous software systems over the years, he is most proud of the award received for software developed and used to help those deployed during Operating Iraqi Freedom and Operation Enduring Freedom. Greg continues to develop, train, and he tweets @gergnotes.