The Problem.

In many software practices, there is an overemphasis on use case modeling. Often, use cases are presented as the only technique for identifying and analyzing business requirements. However, they only provide a part of the bigger picture. Use cases are an exceptional tool when you are engineering functional requirements. However, overreliance on use cases can make you miss out on other techniques more suitable for non-functional business requirements.

Non-functional business requirements (NFRs) are just as important to the success of your projects as the functional requirements. If your system functions as expected but is not reliable, not maintainable, or not affordable to own, then you risk not having a viable product.

You will often hear of the non-functional aspects of the system being referred to as the ‘-ilities’. These critical aspects of your system affect the quality, design, architecture, implementation, and configurability of your solution and will inform downstream requirements like technical requirements and user interface requirements.

Addressing the critical ‘-ilities’ include:

• maintainabiliy
• adaptability
• quality
• affordability
• availability
• interoperability
• portability
• reliability
• usability
• safety
• security
• and so on….

Without mandates for minimal acceptable levels for each non-functional aspect of your system, your downstream specifications have little chance of being correct and the resulting system will probably not be viable. If you wait until you ship to address non-functional deficiencies, you risk paying 50x to 200x in rework to fix resulting issues. You also risk damaging your reputation with your clients as they experience defects arising from missing your non-functional business requirements.

Many projects that solely rely on use case diagrams without textual context miss capturing, communicating, and addressing critical business process steps, triggers, preconditions, and post-conditions. In the worst cases, you will only see your ‘happy path’ being addresses through overly simplified use cases while you will miss discovering and addressing real exception cases. Once you work in this field for any amount of time, you will experience the stark reality that there are tens-to-hundreds of exceptions for each ‘happy path’. If you only capture what the system should do under normal ‘happy path’ circumstances, then your system is likely not to function well when it meets real-world users with real-world needs.

Negative Consequences.

There are five major problems you should keep an eye out for in the current practice of use case modeling.

1. Many NFRs not being addressed at all.
2. NFRs being engineered are often very poor quality: ambiguous, incomplete, unfeasible, and describe unverifiable goals.
3. Incomplete use case models end up producing overly simple stories with little to no actual value, rather than substantive business requirements and domain specifications.
4. Ignoring exception cases means most of your desired system behavior will remain unspecified. The downstream designs and implementation will not meet the unspoken expectations of your users and stakeholders.
5. Anemic or incomplete business requirements and domain specifications that do not address what your system should do under all realistic business operations, inputs, and states, will lead your designers and developers to make incorrect assumptions, ignore critical cases, or build a system that will not easily solve your users needs.

These problems result in systems that are unreliable, unstable, and unsafe. These all-too-common failings across all industries are a leading cause of the ‘Software Apocalypse’

The solution: use the right tools for each job.

Avoid the trap many projects fall into. Do not apply use case modeling as a substitute for business requirements or domain specifications. Use case modeling is an identification and analysis technique, and should not be mistaken for business requirements or domain specifications. You can apply use case analysis to identify and explore functional requirements, but you also need to produce high-quality business requirements and domain specifications in order to clearly communicate across your teams.

Use cases are an indispensable tool to ensure business requirements and domain specifications are complete and you have addressed all edge cases, but they are not an adequate substitute for actual domain specifications and business requirements.

Requirements engineers must use analysis techniques appropriate for the business requirement and domain specification being produced. Functional requirements differ from non-functional requirements. Even specific kinds of nonfunctional requirements require different tools and techniques than others. For example, addressing quality concerns differs vastly from security or availability concerns.

Summary.

Vetrify builds tools to help you ensure your projects are on track. I started Vetrify to help you ‘vet’ various aspects of your software projects and processes and give you access to all the tools and knowledge I have gathered over the years to stay on-track and maximize your chances of success. You want to ensure your team does not accidentally overlook and major type of requirement. This is where Vetrify can help you be sure you have all your bases covered.

I hope this helps you succeed in your next project or improve your current one.

Best of luck,

Matt Cochran - CTO and Founder, Vetrify