2

We have a system that is largely configurable, that can be organized in different architectures, and I'm struggling to write its requirement specification. I'll give an example

  • Module 1 does A
  • Module 2 does B
  • Module 3 does C

The system can be configured to have any combination or all of the three modules. How do I write the requirement?

1) The system shall be configurable by Engineering to do A.

2) The system shall be configurable by Engineering to do B.

3) The system shall be configurable by Engineering to do C.

4) The system shall be able to do A.

5) The system shall be able to do B.

6) The system shall be able to do C.

I like the first 3. The next 3 however will not necessarily always be true (if system is configured with modules A and B, requirement 6 will be false).

Shall I complete requirements 4 to 6 with "if the system is configured to do so"? Are 4 to 6 necesssary at all?

Thanks for your help!

EDIT: So basically the question is, how do you write a requirement when the system should be able to something only under a certain configuration?

  • [Should] I complete requirements 4 to 6 with "if the system is configured to do so"? -- That's what I would do, assuming you even need to say that. – Robert Harvey Jan 12 '17 at 18:46
  • 1
    Your focus is on "a system that can" and you talk about modules. That means you already started designing, you should stick to just listing the pure requirements instead. That would be A, B and C. You may want to add "without intervention of engineers" but you do not think or talk architecture. And you start your question as if the system is already there, what does that mean? – Martin Maat Jan 13 '17 at 7:04
  • Well @Martin, the fact is the system is there. It was originally developed without (!) having written the requirements (there are for each module, but not for the whole system) and now for a series of reasons we need to write them. That's why is difficult to avoid "start designing"... – Paul Jan 13 '17 at 7:22
  • @Paul Aha, so you need system integration requirements now that folks figured existing components should be able to work together. That could be a new project altogether. It sounds like you want to define for each component what it needs to produce in order to meet other component's needs. Remember: write what, not how. – Martin Maat Jan 13 '17 at 10:00
  • Thanks for the comment @MartinMaat. It's more like this: the system does already integrate different components, and the requirement specification for each component do exist also. The thing is it has been historically viewed as a conjunction of these components - never as a system as a whole. Now there is an interest (a need I should say) to develop the system as a whole, and hence the need for "system requirements" rather than a collection of component requirements. And yes, it is a new project altogether, I have a few hundred hours assigned for this task. – Paul Jan 13 '17 at 10:09
1

1. Functional requirements

1.1. System shall be able to do A, B, C.

2. Non-functional requirements

2.1. Configuration management

2.1.1. System shall be configurable to do one or more of the features mentioned in FR#1.1 simultaneously.

2.1.2. It shall be possible to change configuration mentioned in NFR#2.1.1 on the go / with service interruption for up to one hour / etc.

1

How about a truth table

        configuration
          1  2  3
feature A t  f  f
        B t  t  t
        C f  f  t
  • Not sure if that works. The main thing is to make clear: the system shall be able to do A if configured to do so; the system must be configurable. – Paul Jan 13 '17 at 7:45

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.