Category Archives: Software requirements specification

The artifacts we create when managing requirements, the process of creating them, and how to use them. The SRS is one of many requirements models. It specifically documents the details needed by an implementation team to guide the development of the software product.

Communicating Intent With Implementers

By Scott Sehlhorst | July 17th, 2006

Giving a functional spec to developers and testers is not sufficient for creating great software. To a developer, a spec is only the what and not the why. And for a tester, the software requirements specification is neither. Use cases provide the why that explains the intent of the system for the implementation team.

Posted in Communication, Product Management, Requirements, Requirements Models, Software requirements specification, Use Cases | Tagged communicating intent, managing data, MRD, quality assurance, software development process, status report, status reporting, use cases | Leave a comment

Foundation Series: Data Dictionary Definition

By Scott Sehlhorst | July 13th, 2006

What is a data dictionary and how is it used when communicating and managing requirements?

Posted in Foundation series, Requirements, Requirements gathering, Software requirements specification | Tagged Business Analysis, data dictionary, Foundation series, managing data, managing requirements, object oriented analysis, ooa, UML Modeling | 2 Comments

Writing Passionate Requirements

By Scott Sehlhorst | June 15th, 2006

One of the ten big rules of writing a good MRD is writing passionate requirements. What in the world is a passionate requirement [they were all wondering]? When you believe in the product, are committed to the work, and aren’t bored, you can write passionately. The goal of a requirement is to create sustained understanding. A dry document can create understanding, but an engaging document will sustain it.

Posted in Product Management, Requirements, Software requirements specification, Writing | Tagged business requirements documentation, good requirements, managing data, passionate requirements, product requirements, requirements documentation, software requirements, writing business requirements, writing passionate requirements, writing requirements | 9 Comments

Writing Atomic Requirements

By Scott Sehlhorst | June 14th, 2006

One of the ten big rules of writing a good MRD is writing atomic requirements. Just as verifiable requirements must be concretely measurable as having been met or not, so must atomic requirements. If a requirement has multiple elements that can be implemented separately, it is not atomic.

Posted in Product Management, Requirements, Software requirements specification, Writing | Tagged atomic requirements, business requirements documentation, good requirements, managing data, product requirements, requirement atomicity, requirements documentation, software requirements, writing business requirements, writing requirements | Leave a comment

Writing Verifiable Requirements

By Scott Sehlhorst | June 13th, 2006

One of the ten big rules of writing a good MRD is writing verifiable requirements. Verification is both a function of having a precise goal, and having the ability to affordably measure the requirement. A precise goal is a verifiable requirement if we can clearly answer “yes” or “no” when asked if the requirement has been implemented. We also face the practical realities of being able to measure the results profitably.

Posted in Product Management, Requirements, Software requirements specification, Testing, Writing | Tagged business requirements documentation, good requirements, managing data, product requirements, requirements documentation, requirements verification, software requirements, verifiable requirements, writing business requirements, writing requirements | Leave a comment

Writing Unambiguous Requirements

By Scott Sehlhorst | June 12th, 2006

One of the ten big rules of writing a good MRD is writing unambiguous requirements. Ambiguity is a function of communication. The writing can be generically ambiguous, or ambiguous to the writer. A requirement could be precise in intent, but ambiguous in interpretation by the reader. Understanding our audience is as important as precision in language. We write unambiguous requirements because misinterpretation of requirements is the source of 40% of all bugs in delivered software.

Posted in Outsourcing, Product Management, Requirements, Software requirements specification, Writing | Tagged ambiguous requirements, business requirements documentation, clear requirements, good requirements, managing data, product requirements, requirements documentation, software requirements, unambiguous requirements, vague requirements, writing business requirements, writing requirements | 5 Comments

Writing Consistent Requirements

By Scott Sehlhorst | June 9th, 2006

One of the ten big rules of writing a good MRD is writing consistent requirements. Consistency within an MRD has two dimensions that are important to requirements – logical consistency and grammatical consistency. There is also the element of writing an MRD that is consistent with other documentation – external consistency.

Posted in Product Management, Requirements, Software requirements specification | Tagged business requirements documentation, consistent requirements, good requirements, managing data, product requirements, requirements documentation, software requirements, writing business requirements, writing requirements | Leave a comment

Writing Complete Requirements

By Scott Sehlhorst | June 8th, 2006

One of the ten big rules of writing a good MRD is writing complete requirements. We identify problems and opportunities in the market. We determine that one of these problems is valuable enough and practical to implement. Then we have to write the requirements, and make sure that the requirements will completely solve the targeted problem.

Posted in Product Management, Requirements, Software requirements specification | Tagged business requirements documentation, complete requirements, good requirements, managing data, product requirements, requirements documentation, software requirements, writing business requirements, writing requirements | 1 Comment

Writing Design-Free Requirements

By Scott Sehlhorst | June 2nd, 2006

topsyWidgetPreload({ “url”: “http%3A%2F%2Ftynerblain.com%2Fblog%2F2006%2F06%2F02%2Fwriting-design-free-requirements%2F”, “style”: “big”, “title”: “Writing Design-Free Requirements” }); One of the ten big rules of writing a good MRD is writing requirements that do not specify design. How do we specify enough detail to be actionable without constraining the engineering team? How do we trust our developers to do the right thing? The [...]

Posted in Design, Product Management, Requirements, Software development, Software requirements specification, Writing | Tagged business requirements documentation, design-free requirements, good requirements, managing data, product requirements, requirements documentation, requirements vs design, software requirements, writing business requirements, writing requirements | 2 Comments

Writing Concise Requirements

By Scott Sehlhorst | May 31st, 2006

One of the ten big rules of writing a good MRD is writing concise requirements. We have to minimize the amount we write to avoid information overload. We also need to make sure we write enough to get the message across. How do we strike the balance?