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.
Gathering requirements means just that: collecting them.
Clarifying requirements means making sure that those requirements are clear and unambiguous. You need clear and unambiguous requirements so that there is no dispute with the customer over whether or not something that was asked for has been provided.
One way to clarify requirements is to write acceptance tests. Acceptance tests are tests that, if they pass, indicate that the requirement has been fulfilled.
// Acceptance Test
public void GetRandomNumber_ShouldReturn4()
{
var result = GetRandomNumber();
Assert.IsEqual(result, 4);
}
// Implementation
public int GetRandomNumber()
{
return 4; // Chosen by fair dice roll. Guaranteed to be random.
}
If you're having difficulty with things like scope creep, inaccurate time estimates and disputes over completion of requirements, one way to refine those things is to write a Software Design Specification, including the classes and interfaces it would take to fulfill the requirements. This can be combined with the Ubiquitous Language of DDD to get a clear understanding of the scope of a project (from both the developers' and customer's perspective), and what it takes to declare success on each requirement.
Further Reading
Clarifying Requirements
Best Answer
“All transactions should be encrypted.”
This is a non-functional requirement. You claim that it is not measurable. Why wouldn't it be? I can make a test which will pass if a given action requires HTTPS, and fail if it works through HTTP.
It doesn't mean it is a useful requirement. Having just HTTPS doesn't mean transactions are secure. You may have an invalid certificate. Or an outdated version of SSL which was proven to be unsecure. However, just stating that “all transactions should be encrypted” is a good start, and from there, you can expand into a range of more technical but still verifiable requirements, such as that the website should have a rating of A+ on Mozilla Observatory, given that a test will be obvious to do, thanks open source.
If you deal with financial information, make sure the requirements are drafted by a security expert in collaboration with a lawyer and then reviewed by other security experts. The actual requirements will probably be verbose and very specific, requiring a precise version of SSL and a precise certificate authority, detailing audits and logs and how those logs are stored, etc. “All transactions should be encrypted” is ways too general: should I simply use HTTPS between the customer and my reverse proxy? Or should I keep the whole chain encrypted, down to the database?
“The system should make it easy to add new functions.”
This is not a requirement. Don't write it down, since you can't do a test which will unambiguously show that the requirement is fulfilled. In general, terms such as “easy,” “fast,” “beautiful,” “comfortable,” “convenient,” “pleasant,” are a good sign that this is not a requirement. A requirement needs to be perfectly objective; independently of the person testing the conformity of the system to the requirement, the result should always be the same.
What could be measured, however, is the maintainability index, and it's here that non-functional requirements could be useful. For instance, by telling that:
you are providing measurable criteria which will result in a pass-fail test.
“The system should present understandable error messages.”
This is not a requirement either. Even worse, it imposes implementation, and limits the work of interaction designers. It's like to say that the code should contain methods of ten LOC or less—it makes no sense to restrict developers for no reason.
It is one thing to tell that “The buttons should be pretty.” You do write a useless requirement, but at least it doesn't do too much harm outside the requirements document. It is a different story when you end up with requirements such as “The buttons should have nice round corners and have a beautiful shadow.” Not only the requirement is still useless, but now it forces the designer to take decisions which would result in a poor interface, instead of doing her job.
Without the “understandable error messages” constraint, an interaction designer can bring her actual skills to do a product which would be understandable, for instance by getting rid of error messages in the first place. When such messages are relevant, the interaction designer would ensure they are actually reflecting the user approach in order to be understandable (given that cultural differences may make them much less understandable when translated into other languages).
See also
Functional or non-functional requirement?