From: Andrew Gabb (agabb@tpgi.com.au)
Date: Sat Dec 13 2003 - 22:51:01 EST
Monterey, Laura L CONT wrote:
> We may be about to make the very mistake you warn about. Or a
> variation of it. Our SRS does include high-level requirements,
> but it also seems to get quite specific. If high-level
> requirements ought to be broken out separately, I'm guessing they
> ought to be in the Project Plan or the ConOps. Is this correct?
No, neither of these documents contains requirements as such, Laura. The PP usually contains some 'business goals', objectives and system overview (as requirements content), and the ConOps/OCD is an expression of future activities. There can be serious problems in trying to develop requirements and ConOps at the same time or to put them in the same document. (More in the OCD papers at http://www1.tpgi.com.au/users/agabb/)
In my view, it's *very* important to identify the user/operational requirements in isolation (more or less) from the solution, even if this is just a page or two.
> Should we look at our draft document (the result of our first
> requirements sweep -- reqs were cleaned up a bit, categorized,
> presented in numbered paragraph format) and see if we have
> inappropriately combined them? I ask because we may not have the
> staff or the time to create separate documents.
Fortunately or unfortunately, neither the 498 SRS nor the IEEE SRS is designed as a top level document. They describe the specific requirements to be implemented in a software item/unit/element, plus the subsequent analysis and derived requirements, plus some other important stuff like interfaces and qualification. An SRS does not normally contain much of the information that's in an SSS or SSDD, for example, and does not tend to have a good structure for describing those things which are not directly software related.
The danger of putting this in the SRS is that you are 'rushing' into software implementation issues and mixing high level system/project information with low level technical sofware information (and possibly system design with software design - remember that I'm a systems engineer first). I like the separation between these two because (a) it forces you to do one before the other, which allows a relatively clear mind for the task, and (b) it provides a natural location for quite different types of information, and (c) because it's essential in large projects anyway (because you may have a number of HW and SW CIs in your system). As I've stated here before, the user interface design is actually part of system design, and an imposes requirements on the software.
Now you *could* (and you may be politically obliged to) incorporate the system/project stuff in a modified SRS called an SSRS (the first S is for 'system and') for a software-only project, and use the SSS/SSDD as a checklist for useful contents. This would mean an 1 or more extra top level sections.
However, I make this separation even on the small projects (10 KSLOC) I do for small-medium businesses. Sometimes the top level document is very small (1-2) pages, and sometimes the SRS is very small, or not much more than a collection of notes. One big advantage I find is that the separation is quite natural, and makes the writing of each much easier. Otherwise you keep finding that you want to put some important information somewhere, and it doesn't really fit the template - so you either leave it out, or jam it in somewhere where it gets lost.
But my fundamental message is that the SRS is not intended to be a top level document. If you use it as such, it often means that you're omitting important (and precursor) system/project activities, or merging them in with lower level software req/design activities. In the latter case, a common problem is that the decision making is flawed, because of conflicting information and priorities.
Andrew
-- Andrew Gabb email: agabb@tpgi.com.au Adelaide, South Australia phone: +61 8 8342-1021, fax: +61 8 8269-3280 ----- ------------------------------------------------------------------------------- To send a message to this mailing list send it to re-online@it.uts.edu.au. To unsubscribe from this mailing list, email majordomo@it.uts.edu.au with the message `unsubscribe re-online' in the BODY of the mail.
This archive was generated by hypermail 2.1.6 : Tue Dec 16 2003 - 12:20:52 EST