I am confused with what's the different between clarify and gather. I know using interview, observe or questionnaire can to elicit the requirement we want, but how to clarify the functional requirement?
Requirements Gathering – Process to Clarify Functional and Gather Non-Functional Requirements
Requirementssoftware
Related Solutions
I think that you are thinking about this a little too hard. Functional and non-functional requirement are not really as separable as you are suggesting, Take the login case for example.
The user SHALL be able to log in through a web interface. Technically, this is a functional requirement.
The system MUST respond to log in requests within 1 second. Technically, this is a non-functional requirement.
Either way they are both just as important regardless of specific classification.
Requirements can come from any number of places. You might want to have better performance than a competitor. A customer might have specific needs. There might be a request from marketing or sales. There isn't one place were they come from. Though, you could probably abstract away all the different sources and refer to them as customers. Ultimately that is what they are.
You can identify the difference using the following metric. Functional requirements describe what a system will do. A non-functional requirement specifies how it does it.
“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:
Requirement 12.34: maintainability index
Every method should have a maintainability index of 60%.
Every class should have a maintainability index of 75%.
In average, the system should have a maintainability index of 95%.
The maintainability index of Java and JavaScript code is measured using SonarQube definitions specified in appendix C, part 2. Bash scripts are excluded from the maintainability index. If the project needs to use an additional language, this document should be revised.
The measurement is limited to the code which is written specifically for the project. All third-party libraries, would they be imported through package managers such as npm, or committed directly to the version control, are excluded.
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).
Best Answer
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.
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