Channels ▼

Embedded Systems


Requirements Management

One of the tough points we found was the requirements management area where we were informal:

  • SCM requirements are well-known. Making a new SCM system is not like developing new business software. You don't have to understand what customers want because you can be your own customer. You do understand what you are talking about, which is essentially good for software development. Then there is a whole set of bibliography on the subject. If you need to understand what a "repository," "revision," or "item" is, you can find a book, article, or a website where it is described.
  • The entire team works together identifying and deciding about functionalities in a hierarchically flat structure. Clearly defining what had to be done, one of the main targets when dealing with requirements, was not as important for us because we all shared the knowledge.
  • We weren't using user stories or other Agile requirement-management alternatives. We used a full-feature list decorated with descriptions only to explain our product's innovative capabilities.

It was clear we had to improve how we were dealing with requirements. The first step was introducing them as first-level players in Defect Control; see Figure 6. This way we were able to link tasks with requirements, tests, analysis, design activities, and the like. A traceability matrix (not a shaped matrix, but all the required information) was made available and we were able to grasp the impact of a change in a certain requirement. This was neither easy nor quick. Understanding and making the best use of registering each requirement took time and we are still adapting to it. Beyond CMMi, the internal motivation was creating an entire maintained catalog—not just functionalities, but also decisions that would help reviewing why a certain capability was (or wasn't) there. Basically, this was the benefit of requirements management we knew in advance, but it took time to spread throughout the team.

[Click image to view at full size]

Figure 6: Dealing with requirements.

Related Reading

More Insights

Currently we allow the following HTML tags in comments:

Single tags

These tags can be used alone and don't need an ending tag.

<br> Defines a single line break

<hr> Defines a horizontal line

Matching tags

These require an ending tag - e.g. <i>italic text</i>

<a> Defines an anchor

<b> Defines bold text

<big> Defines big text

<blockquote> Defines a long quotation

<caption> Defines a table caption

<cite> Defines a citation

<code> Defines computer code text

<em> Defines emphasized text

<fieldset> Defines a border around elements in a form

<h1> This is heading 1

<h2> This is heading 2

<h3> This is heading 3

<h4> This is heading 4

<h5> This is heading 5

<h6> This is heading 6

<i> Defines italic text

<p> Defines a paragraph

<pre> Defines preformatted text

<q> Defines a short quotation

<samp> Defines sample computer code text

<small> Defines small text

<span> Defines a section in a document

<s> Defines strikethrough text

<strike> Defines strikethrough text

<strong> Defines strong text

<sub> Defines subscripted text

<sup> Defines superscripted text

<u> Defines underlined text

Dr. Dobb's encourages readers to engage in spirited, healthy debate, including taking us to task. However, Dr. Dobb's moderates all comments posted to our site, and reserves the right to modify or remove any content that it determines to be derogatory, offensive, inflammatory, vulgar, irrelevant/off-topic, racist or obvious marketing or spam. Dr. Dobb's further reserves the right to disable the profile of any commenter participating in said activities.

Disqus Tips To upload an avatar photo, first complete your Disqus profile. | View the list of supported HTML tags you can use to style comments. | Please read our commenting policy.