Requirements & Requirements Management

[Answered] The Most Asked Questions About Writing Requirements

By |

writing requirements

“Needs.” “Features.” “Requirements.”

What your team calls the things it wants to achieve with a product isn’t important. The highest priority should be ensuring a product’s promise, functionality, appearance, and value are all clearly and effectively defined for a variety of stakeholders. And writing requirements plays a big role in that.

We recently held a a very well received webinar where we walked through the different ways teams can write better requirements. We also talked about how improving requirements benefits products by anchoring alignment through the chaotic shifts of development.

Below is a recording of the webinar, in addition to expert answers to some of the most commonly asked questions about writing requirements.

Expert Answers to Commonly Asked Questions About Writing Requirements

Q: What’s the best way of using Jama Connect for correlating stakeholder needs with multiple stakeholders and/or stakeholder groups?

A: There are a few options. Stakeholders could be a global pick-list where you have multi-select on the stakeholder need. Another option would be treating stakeholders like a unique item type and relating to the stakeholder needs. These options allow many-to-many relationship and filter.

Q: To know if something should be a requirement or a design decision, what would be a good rule to apply? For example, if the background of a user interface shall be blue.

A: It comes down to it being “necessary” or a “need” – i.e. the user will NOT use it if any other color than blue, then it is a requirement. If the color blue is more of a design aesthetic, and not a “need” than it’s a design choice.

Q: What’s your opinion on designers working in tandem with the writer creating the requirements doc? (example: listing several specific requirements and following with a mockup of how it should look).

A: Having back-and-forth with designers about the requirements could actually help ensure the requirements are well written and understood. This engagement avoids the “over the wall” approach where requirements are written without input or visibility from other teams (who just receive a document tossed to them). You’d want to make sure when collaborating with the designers that the requirements are understood to be the needs of the system while the design is the response to that need (and not the other way around!).

Q: How do you recommend writing a requirement which is “testable”, unambiguous, limits to one outcome without limiting possible solutions? Are you stating that the requirement is only a description of the problem? No solution even inferred?

A: Requirement “templates” help with this which we cover in the webinar. But yes this is the goal to not constrain a specific solution/design in the requirement. Requirements don’t necessarily limit one solutions but it should be “testable” from a pass/fail perspective

Q: Sometimes is difficult to differentiate between system requirement & software requirement, any advice on this?

A: Good question! Typically the system requirement will speak to the interaction across subsystems, modules or components. Also the system requirements will verify the fulfillment of a system need through the interaction of SW systems. There is a concept of a system-within-a-system where, in some instances, the SW is a system in itself, but is intended to to meet the needs of a broader functional need.

RELATED POST: How to Perform Better Impact Analysis on Upstream and Downstream Relationships

Q: How do you coach your customers on requirements decomposition?

A: First I suggest coming up with a System Architecture, then identify top-level requirements that are dependent on the various subsystems. From that allocation, you know Subsystem A needs to decompose to subsystem requirements.

Q: How to clearly differentiate between functional and non-functional requirements. (usually if most of the non-functional req can be categorized as functional if an assertion is provided). What about category of requirement related to timing and execution deadline of a function?

A: From an authoring perspective I’d say a functional requirement is something the end user needs to validate – we have a full blog on functional vs. non-functional requirements if you want to learn more! From a tool perspective Categories could easily be differentiated using a pick-list or a tag in your requirements management solution (like Jama Connect).

Q: Do you guide customers to write requirements for software differently that how you would write them for hardware?

A: Software requirements do not necessarily need to be written differently from hardware requirements – however, some methodologies may dictate that they are different. For example, an Agile methodology may see more user story based authoring style. The key is more that the requirements, whether software or hardware, clearly communicate the need. In some instances the software may further breakdown into Agile-style stories while hardware requirements may not (again, depending on the methodology).

Q: For System of System, do you prefer first defining requirements at higher level and then at interfaces ?

A: I would say yes, that way you ensure end user is validating the top level needs first before defining lower level interfaces.

RELATED POST: 8 Do’s and Don’ts for Writing Requirements

Q: As one improves writing requirements over time (as was mentioned) for requirements that have already been utilized for prior products, how do you make those changes without impacting prior testing to the previous version of the requirements?

A: Some governance method or change control board/team should encourage changes to requirements to improve them for future releases/product variants. This may or may not impact the test of a previous version, it really depends on the specific example I’d say.

Q: Can you give a real-life-like example for taking meta-data out of the requirement statement?

A: Here is something that hopefully illustrates the point:

  • Before: The product shall be blue, which is more important than whether or not it is light weight.
  • After: The product shall be blue (priority: high). The product shall have a weight under 10 grams (priority:medium)
Q: How can we group requirements which are cross functional i.e have mechanical requirements/thermal requirements/electrical? How to decompose the subsystems?

A: In a tool like Jama Connect, I recommend a multi-select field on the requirement – e.g. “Impacted Disciplines” so then you can easily filter which disciplines need to decompose the requirement. Another alternative is using Tags or perhaps a separate item type called “Architecture” so you can allocate requirements to a specific sub-system. Then the owner of that subsystem can see all the related requirements they need to decompose.

Q: What advice would you provide when writing a PRD for a next revision or improved version of the product or does it not differ?

A: The guidance for writing the requirements is the same, but more importantly is to write a full PRD for the improved version rather than just a delta document. Many organizations will produce only a list of deltas for each new version, which eventually leads to a lack of clarity about the full set of requirements for later revisions. Jama Connect can help with managing these changes and making the process more efficient.

RELATED POST: How to Write an Effective Product Requirements Document

Q: Can design specs of one module become requirements for another module?

A: There is usually a close relationship, but not exactly the same content. The design spec for a system will describe what the architecture of the system is and how the components of the system interface to each other. These interface specification often then result in requirements on the component to be compatible with that interface.

Q: With a large feature, do you recommend new requirements for each version/iteration of the feature?

A: Yes, this is highly recommended. It’s also recommended to ensure that you maintain a full list of requirements for each new version, not just a list of changes.

Q: Please explain why requirements are not written in the Change Request (CR). Explain the difference between CR and requirements.

A: A change request is describing a change to existing requirements or adding new requirements after approval. As a result, part of the CR will be new requirement text, but it will also include and explanation for why that change is justified and analysis of impact.


Jama Software
Latest posts by Jama Software (see all)