One strategy:
- Consider the SRS ID as just a number, and don't imply any strong notion of consecutive order (The social security number is a reasonable example.)
- Don't recycle numbers. When an ID in a sequence is deleted, mark it "Deleted", "Deprecated", etc. I prefer to keep the requirement text in the deleted item so that I have a running record of the requirement evolution. If you choose to do this, mark the deleted text obviously, for example a strike-out font.
- #2 implies that new requirement additions will never occur "in place"; rather, they are always appended to the document.
- This strategy can become difficult to organize or cluster hierarchically as changes accumulate, so tag each SRS ID with a meaningful label for searching, i.e. [GUI], [DB], etc.
There are other strategies, such as using dotted decimals to cluster requirements, for example:
- 1.0 GUI
- 2.0 DB
- 3.0 Processing
As you might guess, the respective requirements should be ordered under the top-level number accordingly: 1.1, 1.2...for GUI, 2.1, 2.3, 2.4 for DB, etc. Note that this strategy will need some form of controlled method for managing deletions and additions.
The key thing to enforce in a requirements document: once an ID has been used for a requirement, it cannot be used again different requirement. In other words, if SRS 1234 was used and then deleted, it cannot resurface later. (Allowing it to do so wreaks absolute havoc on requirements traceability over the course of an evolving project.)
Note that virtually any SRS organization/structure will have deficiencies. Pick the one that suits your development environment and your application needs. (For example, the strategies above work reasonably well in highly-controlled development environments, such as those monitored by the FDA or other governmental bodies.)
Finally, consider using a requirements management tool. There are good ones out there (open source to $$$$$) that will take care of all of this for you.
I'm going to rely upon the SWEBOK (Software Engineering Book Of Knowledge) to guide my answer.
In the Software Requirements* chapter, we're provided with more formal definitions of the terms needed for your question.
Functional requirements describe the functions that the software is to execute; for example, formatting some text or modulating a signal. They are sometimes known as capabilities.
Nonfunctional requirements are the ones that act to constrain the solution. Nonfunctional requirements are sometimes known as constraints or quality requirements.
I point those out because there appears to be some overlap in the way you have been requested to generate your document. You stated: A SRS should only have functional, non functional and constraints
and based upon the SWEBOK / IEEE definition you can see that non-functional requirements and constraints are one and the same.
And while some may protest of overkill, there are three main documents related to requirements work.
System Definition Document This document (sometimes known as the user requirements document or concept of operations) records the system requirements. It defines the high-level system requirements from the domain perspective.
System Requirements Specification In this view, system requirements are specified, the software requirements are derived from the system requirements, and then the requirements for the software components are specified.
Software Requirements Specification establishes the basis for agreement between customers and contractors or suppliers (in market-driven projects, these roles may be played by the marketing and development divisions) on what the software product is to do as well as what it is not expected to do.
So the problem with all of that is it appears clear cut when explained, but it ends up being muddy when implemented. To help focus my answer, I'm going to ignore the System Reqs Spec as it's a huge topic and not quite necessary for your question.
The primary challenge you're encountering is that you are mixing your SDD and your SoftRS (software) documents. Since the two documents are communication bridges between three camps, it's natural and unavoidable that you'll see some overlap between the two. The SDD is a bridge between the client and the analysts, whereas the SRS is a bridge between the analysts and the developers.
So how do you draw the line between the SDD and the SRS? Let's go back to the System's Engineering trinity:
And they really should go in that order because when we look at the V-model, we use those three in order to work our way through the layers. You start with the what
& why
at the system layer. As you capture those, you start generating ideas for the how
, which goes into the next layer below in the V-Model. "Eventually" you finish up with a particular layer and you start revising the layer below in the same manner. The difference on the lower layers is that the upper layer's how
becomes this layer's what
.
Blah, blah, wall of text, let's tackle your questions.
FR 1.1 : Have I incorporated a design idea here, would " the system shall have a registration form" be a better functional requirement?
I'm going to start off with "meh" for an answer. "shall display" vs "shall have" on a form that requires user interaction is kind of pointless. If an argument erupted on a real project over the semantics between those two forms, I'd consider that a huge red flag and try to bail on the project. Seriously.
"Shall display" implies "have" whereas "shall have" implies "display" in this case. To be fully pedantic, you would need at least "shall have and display" to make it clear. Any of those three variants is fine though.
F1.2 ,2.3 : Is this not singular? Would the conditions be better written for each its own separate requirement
They are certainly related, and it gets tricky on how you want to express those. I rely upon team norms in this case as I have seen it go either way with equivalent results. The important part is to be consistent in how you handle compound requirements like this.
FR 1.4: Is this a design idea? Is this a correct functional requirement or have I incorporated non functional(performance) in it? Would it be better if I written it like this:
FR1 The system shall display an error message when check is unsuccessful.
NFR: The system will respond to unsuccesful registration form checks within 1 seconds. Same question with FR 2.8 and 2.9.
I would probably break these out, yes. Here's why: The first is providing function (display error message) while the second provides the constraints (specific amount of time) in providing that function. Constraints often change, but the functionality doesn't. By moving the constraint to its own requirement, we can get up front agreement on the functionality and then deal with the constraints (how fast was the message delivered) when we get into implementation.
FR2.3: The system shall check for "completeness", is completeness here used ambigiously? Should I rephrase it?
Your close to explaining completeness with the list of items you provide. However, you could be more clear in specifying what determines completeness or not in each of the items you listed.
FR1.2: I added that the system shall require a "Captcha code" is this a functional requirement or does it belong to the "security aspect" of a non functional requirement.
Depends upon what level of your design you are talking about. At a high level, it's a non-functional requirement because it's a constraint. At a low level, it's a functional requirement because it's specifying a function to be provided.
* SWEBOK is currently in a review state for the next release. Except for the main link, some of the additional links may go stale.
Best Answer
Requirements will grow and change. I don't think anyone could argue that.
How to collect and process incoming requests.
In my experience it helps when gathering requirements if there is a single or very small group of customers acting as a filter for delivering new or updated requirements to a small group of development planners. Anyone from their side can propose or write them up, but delivery should be through only a very small few. The less people that are involved in the exchange from one party to the other, the better.
The purpose of filtering through a smaller set of people isn't to discard or diminish the effort and information others put in, even if duplicate or seemingly unimportant on the surface, but to limit points of failure: lost or mishandled information. It follows on a principle similar to the purpose of encapsulation and interfaces: protect private data, and establish a common protocol for handling similar requests. Let me reiterate: submission of duplicates is ok. As a planner, that tells me the thing they are talking about or proposing is important. Save or record everything.
How to track and organize requirements
In the short term, go low tech
Obviously there are low tech solutions that can be effective to a large degree in organizing and tracking incoming requirements: whiteboards, stickies, posterboards, what have you. These can be great for short term planning. They are highly visible, accept freeform notation, and easy to 'reconfigure'.
In the long term, use a searchable, sortable, linkable software tool
For longer range efforts, some kind of software would be valuable. There are specialized requirements management tools: Doors, Clearcase/Clearquest, and many others. Those highly specialized tools are great at what they do, but are often overkill. Sometimes even a plain old spreadsheet is more than adequate. I personally find general issue tracking systems fairly useful to accomplish this, and right now my favorite is redmine, but others I am sure would be fine too.
With an issue tracking system, anyone you choose to allow can create a 'new issue' or requirement, and add any detail they see fit to include. They can watch the issue, and give feedback to any actions you take with it. You can re-categorize it, adjust priority, rewrite the body, attach supplemental information, associate it with other 'issues', promote to a higher level feature or 'use case' or story or whatever terminology fits your system, ad nauseum. In other words, you can do a lot to create a traceable, sortable, prioritized, history-aware, related list of requirements via issues. Plus being fairly configurable out of the box, and open-source, if the tool isn't quite what I need or want at any point, I can change it fairly easily to better fit the needs of my process.
A final note about tools, some people I have talked with have a good deal of success using plain old text files in a change management and versioning system. They obviously get the benefits of historical versions. They also utilize the base operating system and supplementary tools for finding, linking, and cataloging the requirements. They aren't able to add as much structured, related meta information, but they don't feel they need it, and for their efforts doesn't add enough value. That may or may not be the case for you. The advantage is that is potentially a few less pieces of software on your development stack to manage and maintain.
Post contract award/post project development kickoff requirements
The final aspect of the question, is how to manage requirements after an effort has begun. I think there are two leading thoughts on this, and part of how you handle them depends on the nature of your relationship with the customer: firstly, if under contract at a fixed value, requirements that come in after contract award can be incorporated. The implication is they may change the scope of the effort, so the rate or bill will be higher when those extra items are delivered and accepted; unless an equivalent amount of effort is removed from the accepted proposal. If it is going to a change in scope, you must ensure the customer understands and accepts the consequence, otherwise, those late submissions will have to be tabled.
Second, for the new requirements coming in after the contract is awarded, and the contract is oriented more towards a time and material effort (whatever it takes to get the body of work completed), you can and should be a bit more flexible if the customer insists on including it during that particular go. You will get paid whether you include it or not, so long as everything you say you will do gets done.
If you aren't familiar with them, you may want to look at a Kanban approach and Agile methods. These techniques can help bring focus to the immediate concerns, without necessarily losing sight of longer term development goals.
Present options as 'what if' scenarios and give the customer a choice and the decision
In either case, a 'what if' estimate is a good strategy to employ when negotiating with the customer and your team. Construct a side-by-side comparison of the tasks, their costs, and the schedule as planned, with a column showing the same information for the alternative approaches. Microsoft Project is probably a good candidate for doing this as you can construct different estimates based on a largely similar set of tasks.
However, even a basic spreadsheet is often just as effective for demonstrating how specific changes or inclusions would impact the cost and schedule. A list in this case is probably just as effective as a tree might be in demonstrating the differences. The tool and method you choose to construct these scenarios largely depends on the size of the project and staff (but even triple A software like MS Project has its own limits of usefulness and ability).
Consider these what if scenarios as internal work items and save them for the duration of the project. They were critical demonstrations in the decision making and negotiation process. You may also have to revisit them, or repeat them for a successive round of what ifs.
When preparing what if scenarios, a supplementary explanation of pro's and con's from a technical or implementation perspective (in simplified terms) might be useful for helping to justify why one alternative would have such a significant impact.