Mission:
Maintaining software is hard and therefore expensive and IT departments are often underfunded. However, if they are in a ‘Just do it’ mode then non-functional requirements are easy to be forgotten. The consequences of leaving these NFRs lead directly to the aforementioned maintenance problems and increased technical debt.
NFRs are necessary to completing the story of the IT application. While you might consider 2 or 3 important NFRs (like performance and security), you’ll probably not cover the others extensively enough, or you might miss out on them all together. And if you do allocate time to deal with them, when the project schedule slips, the NFRs may be the first thing to get drop. So, whether you plan for NFRs or not, chances are high you won’t cover them 100% of the time. You should try to avoid adding technical debt and maintenance nightmares to your future portfolio.
Non-Functional Requirements are key to any software / IT program. They cannot be overlooked or ignored. The book provides a comprehensive approach from analysis, architecture and measurement of non-functional requirements. The book outlines the methodology for capturing the NFRs and also describes a taxonomy framework that can leveraged by analyst and architects for tackling NFRs on engagements.
Non-Functional Requirements are key to any software / IT program. They cannot be overlooked or ignored. The book provides a comprehensive approach from analysis, architecture and measurement of non-functional requirements. The book includes considerations for bespoke (Java, .Net and COTS applications). These are applicable to and IT applications/systems for different domains. The book outlines the methodology for capturing the NFRs and also describes a framework that can leveraged by analyst and architects for tackling NFRs for various engagements.
Non-functional requirements refer to a whole slew of attributes including performance, scalability, security, and the various "ilities," such as usability, reliability, and availability. Invariably, requirements definers get wrapped up in how the system is expected to function and lose sight of these elements.
NFR are:
• Difficult to Model – Non-functional requirements vary so much that they lack a consistent method of representation. Without that consistency, they are usually modelled for each specific project.
• Casually-Stated –Many times, the need for a non-functional requirement comes from a nonchalant statement by a user or other stakeholder. It is imperative that stakeholders and project managers clearly communicate and identify what is most important to the project’s overall success. No assumptions allowed.
• Hard to Measure –Non-functional requirements have the capacity to be indefinite, making them difficult to evaluate. Testing methods must then be developed to assess these variable attributes.
