We sometimes write a high-level product description early on, but we don’t refer back to it.

The person who conceives the product knows the business requirements and discusses them verbally with the development team.

We record business requirements in a vision and scope, project charter, or similar document according to a standard template. All project stakeholders have access to this document.

We actively use the documented business requirements on our project, evaluating proposed product features and requirement changes to see whether they lie within the documented scope, and adjusting scope as needed based on business objectives.

The developers think they know who our users will be.

Marketing or the project sponsor believes that they know who the users are.

Target user groups or market segments are identified by management or marketing from some combination of market research, our existing user base, and input from other stakeholders.

The project stakeholders identify distinct user classes, whose characteristics are summarized in the software requirements specification.

The developers are confident that they already know what to build.

Typical users are surveyed with questionnaires or interviewed in focus groups.

We meet with people, sometimes one on one and sometimes in groups, and they tell us what they want.

A variety of elicitation techniques are used, including interviews and workshops with user class representatives, document analysis, and system interface analysis.

They are developers or former users who have little experience and no specific training in software requirements engineering.

Developers, experienced users, or project managers who have had some previous exposure to requirements engineering perform the BA role.

The BAs have had several days of training and considerable experience in collaborating with users.

We have professional business analysts or requirements engineers who are trained and proficient in interviewing techniques, the facilitation of group sessions, technical writing, and modeling. They understand both the application domain and the software development process.

Software is expected to overcome any shortcomings in the hardware.

Software and hardware engineers discuss which subsystems should perform which functions.

A system engineer or an architect analyzes the system requirements and decides which ones will be implemented in each software subsystem.

Knowledgeable team members collaborate to allocate portions of the system requirements to software subsystems and components and to trace them into specific software requirements. Component interfaces are explicitly defined and documented.

We do not reuse requirements.

A business analyst who is familiar with previous projects sometimes knows of requirements that can be reused on a new project, so she copies and pastes the requirements into the new specification.

A business analyst can search through the previous projects stored in our requirements management tool for requirements that are relevant to his new project. He can reuse specific versions of those requirements by using the functions built into the tool.

We have established a repository of potentially reusable requirements, which have been adapted and improved from previous projects. BAs routinely check this repository for requirements that might be usable on their current projects. We use trace links to pull in child requirements, dependent requirements, design elements, and tests when possible when we are reusing a requirement.

We begin with a general understanding, write some code, show the software to some users, and modify the code until they’re happy.

Management or marketing provides a product concept, and the developers write the requirements. Customer stakeholders tell the development team if they’ve missed anything.

Marketing or customer representatives tell the development team what features and functions the product should contain. Sometimes marketing tells the development team when the product direction changes.

We hold structured requirements elicitation interviews or workshops with representatives from the different user classes for the product. We employ use cases or user stories to understand the users’ goals, and we create analysis models to help ensure we identify all the functional requirements. We flesh out the requirements incrementally and iteratively, giving the customers numerous opportunities to improve them.

We piece together oral history, email and voice mail messages, interview notes, and meeting notes.

We write unstructured narrative textual documents, or we create simple requirements lists, or we draw some diagrams.

We write requirements in structured natural language according to a standard template. Sometimes we augment these requirements with visual analysis models that use standard notations.

We create requirements and visual analysis models and store them all in a requirements management tool. Several attributes are stored along with each requirement.

What are “software quality attributes”?

We do beta testing to get feedback about how the users like the product.

We document certain attributes, such as performance, usability, and security requirements.

We work with customers to identify the important quality attributes for each product, which we then document in a precise and verifiable way.

We write paragraphs of narrative text or short user stories; specific requirements are not explicitly identified.

We use bulleted or numbered lists.

We use a hierarchical numbering scheme, such as “3.1.2.4.”

Each discrete requirement has a unique, meaningful label that is not disrupted when other requirements are added, moved, or deleted.

All of the requirements are important, so we don’t need to prioritize them.

The customers tell us which requirements are most important to them. If the customers don’t tell us or don’t agree, the developers decide.

Each requirement is labeled as high, medium, or low priority by customer consensus.

To help us make priority decisions, we use an analytical process to rate the value, the cost, and the technical risk of each requirement, or we use a similar structured prioritization technique.

We just build the system and then fix it if we need to.

We build some simple prototypes and ask users for feedback. Sometimes we’re pressured to deliver prototype code.

We create prototypes for both user interface mock-ups and technical proofs of concept when appropriate.

Our project plans include tasks to create electronic or paper throwaway prototypes to help us refine the requirements. Sometimes we build evolutionary prototypes. We use evaluation scripts to obtain customer feedback on our prototypes.

We think our requirements are pretty good when we first write them.

We pass the specified requirements around to people to get their feedback.

The BA and some stakeholders hold informal reviews when they have time.

We inspect our requirements documents and models, with participants that include customers, developers, and testers. We write tests against the requirements and use them to validate the requirements and models.

The document shows the auto-generated date that the document was printed.

We use a sequence number—like 1.0, 1.1, and so on—for each document version.

We have a manual identification scheme that distinguishes draft versions from baselined versions and major revisions from minor revisions.

The requirements documents are stored under version control in a document management system, or requirements are stored in a requirements management tool that maintains a revision history for each requirement.

They aren’t.

We know where many of the requirements came from but don’t document the knowledge.

Each requirement has an identified origin.

We have full two-way tracing between business requirements, system requirements, user requirements, functional requirements, and nonfunctional requirements.

The delivery date is set before we begin requirements development. We can’t change either the project schedule or the scope. Sometimes we go through a rapid descoping phase to drop features just before the delivery date.

The first iteration of the project plan addresses the schedule needed to gather requirements. The rest of the project plan is developed after we have a preliminary understanding of the requirements. We can’t change the plan much thereafter, however.

We start with just enough information about requirements to prioritize them, then estimate the effort needed to implement the top-priority requirements. We develop our requirements and our software incrementally, planning the requirements for each iteration based on their priority and size. If we need to accommodate more requirements than our plan allowed, we add more iterations.

We base the schedules and plans on the estimated effort needed to implement the required functionality, starting with the highest-priority requirements. These plans are updated as the requirements change. If we must drop features or adjust resources to meet schedule commitments, we do so as early as possible. We plan to deliver multiple releases to accommodate requirements changes and growth. [Note: (c) and (d) are equally good responses for this question.]

When we have written requirements, we refer to them during development.

The requirements documents describe the solution we intend to implement.

Each functional requirement is traced to a design element.

Developers inspect the requirements to make sure they can be used as the basis for design. We have full two-way traceability between individual functional requirements and design elements.

The testers test the software based on how they think it should function.

The testers test what the developers said they implemented.

We write system tests against the user requirements and functional requirements.

Testers inspect the requirements to make sure they are verifiable and to begin their test planning. We trace system tests to specific functional requirements. System testing progress is measured in part by requirements coverage.

We don’t have to think about baselines because we are on an agile project.

The customers and managers sign off on the requirements, but the development team still gets a lot of changes and complaints.

We define an initial requirements baseline, but we don’t always keep it current as changes are made over time.

The requirements are stored in a requirements management tool when an initial baseline is defined. The requirements repository is updated as requirements changes are approved. We maintain a change history for each requirement after it’s baselined. On an agile project, the team agrees on a requirements baseline for each iteration.

The requirements change whenever someone has a new idea or realizes that he forgot something.

We discourage change by freezing the requirements after the requirements phase is complete, but informal change agreements are still made.

We use a defined format for submitting change requests and a central submission point. The project manager decides which changes to incorporate.

Changes are made according to our documented change control process. We use a tool to collect, store, and communicate change requests. The impact of each change is evaluated before the change control board decides whether to approve it.