I’ve received a few requests for help on justifications for Requirements efforts in teams.  Often it’s someone trying to get resources from their management with hopes of understanding and evolving their software process.  The ultimate challenge is identifying the right amount or balance of Requirements Management and Business Analysis will help the team.  Given the caveat that I have never seen two teams that are the same, here goes…

Justification for Requirements Management to the business managers is sometimes a catch-22 situation.  It’s an investment to visualize and breakdown project requirements while understanding the problems that stem in project requirements requires visibility into the software process.  On the other hand, treating IT investments as a black box is a bad idea and can result in missed deadlines, delivering the wrong solution, and a low quality deliverable.  The right amount of process in the software team is a function of how efficiency is managed and optimized.  In other words, manage and measure those things with variability that can benefit from efficiencies.

Here are some general problems that are answered by involving business users via requirements and traceability.  There are some pretty extensive studies that have been done on Requirements Management, Project Management, and Business Analysis which provide literally volumes of information. 

• Stakeholder vs. developer language differences
• Developers and end-users/stakeholders live at different levels of abstractions and therefore communicate using different context and vocabulary.  It’s important to capture the stakeholder requirements and map them to the development domain. 
• Change happens everywhere - in the business domain (just as well as the development domain)
• When the business learns something about the business environment the Development team needs to assess the impact that change will have on the project.  Without a set of up to date requirements which are mapped to development artifacts (design, architecture, tasks, bugs, etc…), it’s very difficult rank the change request relative to the existing state of the project and resources.
• Stakeholder need to be part of the extended team
• Validating requirements and their implications with stakeholders or end-users will not only foster a feeling of partnership with stakeholders, but also minimize complexity derived from scope creep.  Stakeholder reviews need to enable stakeholders to understand status and implications of their decisions.
• Delivery contracts for building trust
• Building trust based on accountability and delivering what is promised can be accomplished using Requirement Specifications.  Ultimately, if you can’t describe what is going to be delivered then there is a good chance it will never be delivered.
• Quality Assurance (QA) needs to know what/how to verify intentions and goals
• QA needs to understand all levels of intent (functional, non-functional, business, etc…) in a system in order to validate the system.  In some cases it may make sense to involve QA in the planning process to ensure testability in the defined requirements.
• Project Planning and Operations are separate
• Planning should feed into Operations and vice versa.  The iteration between the two disciplines requires a series of transformations which enable traceability from high level artifacts such as business goals to low level artifacts such as code.
• Estimating size and complexity requires context
• Deciding on the size, however measured, requires both a top-down structured divide-and-conquer style approach as well as a bottom-up verification that everything fits into the defined higher level context/requirements.  Without this bi-directional checks and balances the code can implement more than you need or the solution can end up not solving the problem.
• Scope management

• Defining the part of the problem that will not be solved is just as or more important than defining the problem you will attempt to solve.  Because they complement each other, defining the part of the problem you will not solve will help specify the other part.

The following are some resources I use when discussing Requirements Management and Business Analysis.  If you have some favorites, I’d love to learn about them.

• Wikipedia
• http://en.wikipedia.org/wiki/Requirements_analysis#Problems -This enumerates a list of problems between developers and users/stakeholders
• http://en.wikipedia.org/wiki/System_Requirements_Specification - System Requirements Specification and a list of deliverable types
• http://en.wikipedia.org/wiki/Systems_development_life_cycle - SLC
• http://en.wikipedia.org/wiki/Business_analyst - Business Analyst definition and breakdown
• Software Engineering Institute
• http://www.sei.cmu.edu/str/descriptions/reqtracing.html
• http://www.sei.cmu.edu/publications/documents/06.reports/06tr008.html   - The Requirements Development and Requirements Management section of the document
• International Institute of Business Analysis
• http://download.theiiba.org/files/BOKV1_6.pdf - Business Analysis Body of Knowledge
• Mike Cohn – Mountain Goat Software
• http://www.mountaingoatsoftware.com/article_view/27-advantages-of-user-stories-for-requirements - Advantages of User Stories for Requirements