I am currently tasked with writing Software Requirements Specification (SRS) document for a project. Effective sharding (based on specific criterion) and Scalability are key requirements of the project.
Scalability is traditionally classified as a non-functional requirement. My question to the community is that if scalability is crucial to a project, would it still be classified as a non-functional requirement? Are their cases when scalability requirements would be best classified as functional requirements?
10 comments:
Your question implies that it makes a difference somehow whether scalability is a functional requirement or a non-functional requirement?
Not necessarily. I am just curious whether scalability is justified as a functional requirement in cases where it is crucial (and not just to be a "buzz" word)?
Precisely, what about situations where your software must specify the guidelines for a sharding layer? For the sharding layer requirements to be testable, shouldn't they appear in functional requirements?
It's a non-functional requirement; but that's purely in the context of accepted official process and terminology. Wouldn't read much into it beyond that.
Also see http://en.wikipedia.org/wiki/Non-functional_requirement and http://en.wikipedia.org/wiki/Functional_requirements
The page on non-functional requirements probably describes your issue best, and even notes scalability specifically.
To augment my previous posting.. Frank, non-functional requirements are still crucial for the whole.
Even something like usability is not "optional", is it ;-)
And scalability is exactly the same.
I'd say that the number of users/expected grow ratio/etc. is a functional requirement.
Scalability is the techies way of expressing that.
If it is has been determined that scalability can only be achieved by sharding, then yes, I would say it is a functional requirement, for the reason you state in your comment.
"Determined" in this context would not mean that there are no other means of scaling, but all other means can be ruled out as too expensive or impractical, for example.
I guess it all boils down to: What is the purpose of the documents you have to prepare (like stu is asking)?
Most likely they would serve as a starting point for planning resources, budgeting and compliance protocols, right?
If that's so, and you feel the sharding layer will play a crucial role in making the project successful, you'd be ill advised to leave it out, I think, lest someone comes up with the implementation being one huge database server that you can only scale up :)
@arjenau and @kay: thanks for the comment. I have been thinking about it and it seems that if specifications about how sharding layer should work they should be a part of the functional specifications. Reason being that the acquirer wants the sharding layer to function in a specific way. Otherwise, it's ok to put it in non-functional specification category. Thoughts?
If a requirement is classified as "Non-Functional Requirement" or "Functional Requirement" just depends on the individual view:
Example: The requirement that a user should get notified before his password expires, or the requirement to support configurable password-complexity rules etc. are for the security team "functional requirements".
(Functionality of the security-subsystem)
From the Business point of view such security requirements are usually listed in the category "Non-Functional Requirements".
For this reason often the term "Quality Requirements" is used as an alternative to "Non-Functional Requirements" which covers many - but not all - requirement groups often listed as "Non-Functional Requirements".
Scalability supports the possibility to keep good response times (a quality requirement from user's point of view) under increased data volume and user base.
The German language uses often the term "Technische Anforderungen" - which is in word-by-word translation "Technical Requirements" to cover requirements which are not "Functional Requirements".
As in your case the scalability seems to be very important, you might decide for 3 main chapters:
1) Business Functionality Requirements
2) Performance and Scalability Requirements for large user base / data volume
3) Other Non-Functional Requirements
e.g. 270 Non-Functional Requirements
Scalability is a non-functional requirement. However, that non-functional requirement can translate into a functional requirement, such as that of creating a document type handler for an existing application that is invoked by a worker process.
It's a non-functional requirement; but that's purely in the context of accepted official process and terminology. Wouldn't read much into it beyond that.
Also see http://writemysqlquery.blogspot.com
Post a Comment