International Project Management Day




Software Requirements Capture Guideline


Quick Summary
Detailed guidelines from an experienced software development executive intent on capturing all necessary requirements, documenting them thoroughly, and ensuring they are well understood. Be sure you're actually building the right thing -- and be sure everyone else is sure, too.


This template requires a Premium Subscription
Please log in. Don't have a log-in? Sign up now. Already a Member? Log in to upgrade immediately and get the file! A Premium subscription is only $14.95/month or $149/year and gets you over 200 templates, guidelines, and checklists.
15-day free trial period for new Premium subscribers! Learn more
Log in to download this file

Username:  
Password:  

What this is

A guideline written by an experienced software development executive, describing how to capture all the requirements necessary to build the right product, and ensure the requirements are well understood. While it will provide a head start to new developments, even existing systems can benefit from requirements documentation; it forms the basis for future modifications. You don't know where you're going unless you know where you are.


Why it's useful

Success in software development is highly dependant on understanding and then capturing requirements, even in an iterative development. However, the quality of requirements specifications varies widely, often even within an organization. Missing, poorly stated, or ambiguous requirements cause problems and result in rework. Combating these problems requires us to ask the right questions to make the requirements specifications better, clearer, and more complete, and then describe requirements in a clear, complete, consistent, unambiguous, and precise way.


How to use it

Follow the key steps provided in the guideline to develop a robust requirements documentation infrastructure in your organization.

Step 1: Determine and document a standard format and contents of requirements specifications.
Step 2: Determine and document the roles involved in the process; for example, who gives the requirements, documents them, reviews them, incorporates comments, answers questions, and authorizes the final build-to specification.
Step 3: Determine and document the process for gathering, documenting, and reviewing the requirements, incorporating feedback and changes, and approving the final specification.

Then, for each specification, follow the documented process to gather and document the requirements for the software product. Ask the right questions to be sure that the intent of the product is understood, and that the format is sufficient to document all aspects of the requirements. Analyze the requirements for consistency, precision, and completeness, to eliminate ambiguity, and to ensure that nothing has been overlooked. Sample sequence diagrams and usage scenarios (use cases) are included.

About the Author

Anita Wotiz has held high-level management positions at a variety of companies and has transitioned from large, government research firms to small start-ups. With over 20 years of software engineering experience, she is adept at tailoring best practices to meet a company's needs, regardless of size, and at putting in place practices that will reap the most benefit for the cost. Her most recent position was VP of Engineering at a small enterprise application software company. Her years of experience allowed her to understand what works, and, sometimes just as important, what doesn't work. Anita has successfully applied her expertise in growing engineering organizations, defining ownership roles and responsibilities, and identifying interfaces between organizations for success in companies large and small. She holds a BS in Mathematics and an MS in Computer Science. She is currently the Coordinator of and an instructor for the new UC Santa Cruz Extension Software Engineering Management program.


This template requires a Premium Subscription
Please log in. Don't have a log-in? Sign up now. Already a Member? Log in to upgrade immediately and get the file! A Premium subscription is only $14.95/month or $149/year and gets you over 200 templates, guidelines, and checklists.
15-day free trial period for new Premium subscribers! Learn more
Log in to download this file

Username:  
Password:  





Related Templates
Configuration Management Plan
A Configuration Management Plan attempts to avoid lost time and expensive rework by documenting procedures the project team will use to control critical components of their project's "products"—hardware, software, documentation, written products, etc.

Requirements Interview Checklist
A requirements interview is a focused interview with a key stakeholder or subject matter expert designed to elicit a specific set of requirements. This checklist is organized into sets of questions you should consider for each interview; important preparation that will increase your credibility and help you make the most of your time with these key resources.

Requirements Management Plan
A requirements management plan captures the tools the team will use to record and track requirements, reinforces the importance of traceability, and articulates the project's risk management and change control strategies.

Requirements Measurement Plan
This template is designed to help you think through how you will ensure that the documented requirements meet the expectations of your stakeholders, both in content and in quality.

Requirements Workshop Planning Guide
Detailed tips and a step-by-step guide to planning a requirements workshop designed to elicit and understand a specific set of requirements. Includes extensive suggestions on planning and conducting the workshop and post-meeting follow-up, along with a sample agenda and general meeting facilitation tips.

Technique Brief - Context Diagrams
Context diagrams are a time-tested method for using simple symbols to illustrate a system's boundaries, benefits, interactions, and data flows. Simple sketches can aid discussions of project features and scope, and detailed graphical interface specifications can improve communication and understanding with non-technical stakeholders.

BURNING QUESTIONHow can I stay on track if they won't let us do requirements work? 
When the conversation with Management is "we don't need to do requirements," we have to start by looking at how Management seems to be thinking of requirements.



©Copyright 2000-2017 Emprend, Inc. All Rights Reserved.
About us   Site Map   View current sponsorship opportunities (PDF)
Contact us for more information or e-mail info@projectconnections.com
Terms of Service and Privacy Policy

Get Our Newsletter
Get our latest content delivered to your inbox, every other week. New case studies, articles, templates, online courses, and more. Check out our Newsletter Archive for past issues.

Follow Us!
Linked In Facebook Twitter RSS Feeds

Got a Question?
Drop us an email or call us toll free:
888-722-5235
Learn more about ProjectConnections, our contributors, and our membership levels and product options.