The Myth called Software Requirements!

By : G.Saravanan

http://linkedin.com/in/gvanan

https://twitter.com/gvanan

http://www.facebook.com/gpgvanan

The Myth called Software Requirements!

1. Can there ever be a complete set of requirements?

• Answer would be NO, there is no such thing as a complete requirements.

2. So, if the answer is NO, how can we build a complete software?

• The Answer is NO, we can never build a 100% customer satisfying software.

3. So, if the answer is NO, how can we improve it?

• The Answer is in the question - We can only improve it!

In case you are wondering how can that be, when we have all the tools in the world to create and manage requirements, think about it again. How many types of requirements do we have nowdays - generally speaking, there are 2 - Functional and Non-Functional.

Most tools and techniques are only geared towards the functional requirements. How about the non-functional requirements? In case you are wondering what is the basic set of Non-Functional requirements which a software requirements should cover, we have an ISO standard for this. Its called ISO/IEC 9126 - Refer to the Quality Metric, there are 4 Metrics all together.

The Quality Metric says the following: ( http://en.wikipedia.org/wiki/ISO/IEC_9126 )

1. Functionality
2. Reliability
3. Usability
4. Efficiency
5. Maintainability
6. Portability

The general list of Non-Functional is much wider (scary as well). The question is How are we supposed to document/model/communicate this and get the confirmation from the customers?

Be it documenting is upfront in a SRS (for Waterfall lovers) or as a story board (for Agile lovers), what is the solution?

• Accessibility
• Audit and control
• Availability (see service level agreement)
• Backup
• Capacity, current and forecast
• Certification
• Compliance
• Configuration management
• Dependency on other parties
• Deployment
• Documentation
• Disaster recovery
• Efficiency (resource consumption for given load)
• Effectiveness (resulting performance in relation to effort)
• Emotional factors (like fun or absorbing)
• Environmental protection
• Escrow
• Exploitability
• Extensibility (adding features, and carry-forward of customizations at next major version upgrade)
• Failure management
• Fault tolerance (e.g. Operational System Monitoring, Measuring, and Management)
• Legal and licensing issues or patent-infringement-avoidability
• Interoperability
• Maintainability
• Modifiability
• Network topology
• Open source
• Operability
• Performance / response time (performance engineering)
• Platform compatibility
• Price
• Privacy
• Portability
• Quality (e.g. faults discovered, faults delivered, fault removal efficacy)
• Recovery / recoverability (e.g. mean time to recovery - MTTR)
• Reliability (e.g. mean time between failures - MTBF)
• Reporting
• Resilience
• Resource constraints (processor speed, memory, disk space, network bandwidth, etc.)
• Response time
• Robustness
• Safety or Factor of safety
• Scalability (horizontal, vertical)
• Security
• Software, tools, standards etc. Compatibility
• Stability
• Supportability
• Testability
• Usability by target user community