blueprintsys.com

Whitepaper

The #1 Reason Your Agile-driven Products Don’t Meet Customer Expectations4 Concepts to Improve Your Non-Functional Requirements

2blueprintsys.com

4 Concepts to Improve Your Non-Functional Requirements Whitepaper

As an IT leader, you need your Agile teams to efficiently deliver products that meet customer needs, work well, and are easily maintained. Too often, however, teams fail to meet this goal; while many companies have worked to improve the quality of their functional requirements (“what” the software needs to do), many haven’t recognized that non-functional requirements (those that define “how well” the software should work) are just as critical, possibly even more so.

Failure to address concepts like performance, usability, security, and regulatory compliance can lead to expensive rework and unhappy customers. Consider the launch of Healthcare.gov: the failure to support enough simultaneous users (a non-functional requirement) took its obvious toll.

One of the biggest questions today is “Where do non-functional requirements fit in Agile”? The answer is that they should influence the acceptance criteria of user stories as well as the definition of done. The problem is that they are often left out of both artifacts.

Non-Functional Requirements at a Glance

• Functional requirements describe “what” a system should do.

• Non-functional requirements define “how well” it should work, providing development teams with constraints and directives that lead them to the best solutions.

Non-functional requirements are so important (and under-emphasized) that Roxanne Miller dedicated an entire book, The Quest for Software Requirements, to the subject. She provides the following user-focused categorization of common non-functional requirement types.

User Needs User Concerns with the Software SystemNon-Functional

Categories

Operation

How well does the system perform for

daily use?

How well is it guarded against unauthorized access?

Access Security

How dependable is it during normal operating times?

Availability

How fast, how many, and how well does it respond?

Efficiency

How accurate and authentic are the data? Integrity

How immune is the system to failure? Reliability

How resilient is the system from failure? Survivability

How easy is it to learn and operate the system? Usability

Non-functional requirements define “how well” it should work, providing development teams with constraints and directives that lead them to the best solutions.

3blueprintsys.com

4 Concepts to Improve Your Non-Functional Requirements Whitepaper

User Needs User Concerns with the Software SystemNon-Functional

Categories

Revision

How easy is it to correct errors and add

on functions?

How easy is it to modify work in different environments?

Flexibility

How easy is it to upkeep and repair? Maintainability

How easy is it to expand or upgrade its capabilities?

Scalability

How easy is it to show it performs its functions? Verifiability

Transition

How easy is it to adapt to changes in the technical environment?

How easy is it to interface with another system? Interoperability

How easy is it to transport? Portability

How easy is it to convert for use in another system?

Reusability

This categorization paints a clear picture of the non-functional requirement types teams should consider

when developing new solutions to meet customer expectations.

Non-Functional Requirements are Incredibly Important…

For business success, meeting non-functional requirements isn’t optional:

• Business pace has increased, as have stakeholder expectations. Competition has increased the need for faster innovation. Time-to-market is critical, leaving little time to rework software to fix performance or security issues. Customers expect products to be available, fast, and easy-to-use. And internal stakeholders depend on them daily to execute business-critical processes, whether in the office or working remotely. They expect your products to meet their performance, availability, and usability needs.

• Technical environments are complex. With simpler technical environments, we could overlook some non-functional requirements with little risk. But software today operates in incredibly complex environments. Solutions span physical locations and leverage diverse technologies, yet they must interoperate securely and perform almost instantly. Testing of non-functional requirements is also more complicated, so requirements must be clear and complete.

• Non-functional requirements guide development teams. They illustrate constraints teams need to understand in order to deliver a usable product. They help teams compare approaches to understand options and tradeoffs, enabling them to make sound decisions. If defined well, they lead the team to design and develop a robust, sustainable product that truly addresses customer needs. Non-functionals point the development team in the right directly to create a product that truly addresses customer needs and interests.

• Missing or misinterpreting them leads to costly rework. The cost comes in the forms of time, money, and respect. Poor non-functional requirements can be particularly catastrophic in Waterfall projects, where they don’t rear their ugly heads until user acceptance testing – 6, 9 or 12 months

4blueprintsys.com

4 Concepts to Improve Your Non-Functional Requirements Whitepaper

after requirements definition.

• Non-functional requirements aren’t optional. Think about regulatory compliance and the importance of security, data integrity, and reliability. Faulty compliance requirements not only put a project at risk, they can put the organization itself in a dangerous position legally and financially.

…But They’re So Frequently Missed

Why do teams fail when it comes to non-functional requirements since we all understand the potential impact?

• Being overwhelmed by their complexity. By their nature, non-functional requirements differ from functional ones. They often compete with other requirements, requiring difficult conversations about tradeoffs of functionality for performance.

• Missing critical stakeholders. Defining non-functional requirements starts with stakeholder identification, but the people who represent them (Security, UX, Legal) can be hard to identify. They’re not part of the core project team, making them easy to forget. This is particularly tough for Agile teams that are accustomed to dedicated teams working together throughout the lifecycle to deliver a product – these stakeholders are not part of the Scrum Team.

• Lacking the right expertise. Non-functional requirements are fairly technical, and many Business Analysts lack technical backgrounds. If they don’t understand certain concepts, they won’t know what questions to ask or how to interpret and document the information they collect. It can also be intimidating, without the proper frame of reference.

• The need to meet deadlines. Deadlines drive projects, and Business Analysts have to meet them. But many non-functional requirements representatives, like legal and regulatory experts, have serious calendar constraints; it’s tough to get time with them for elicitation. So to avoid bottlenecks, business analysts often skip those discussions altogether.

• Making poor assumptions. Project teams operate under a number of assumptions – a common cause of missed non-functional requirements. They think: “We’ve done this a hundred times, so everybody knows…” Assuming development teams understand non-functional constraints leads to a lack of explicit definition and subsequent failure to define them.

• Confusion in Agile. Where do they go? Analysts write user stories, and there may be a Definition of Done, but do non-functional requirements live outside of that? Are they part of those artifacts? Once again, teams run into an “out of sight, out of mind” scenario where if there isn’t a section of a document or an artifact type to remind analysts to record non-functional requirements, they are forgotten about.

The Big Payoff of Improving Non-Functional Requirements

If your team produces substandard non-functional requirements, improving (or actually including) them can have massive impact to project success. And due to their nature, they’re prime candidates for reuse – defining them in a central location and using them across multiple projects.

• Non-functional requirements stakeholders are common. Business Analysts interview similar stakeholders across projects. To understand compliance and security needs, they talk to legal, finance, and IT representatives. For usability, they talk to user experience designers. Organizations

Defining non-functional requirements starts with stakeholder identification, but the people who represent them (Security, UX, Legal) can be hard to identify.

5blueprintsys.com

4 Concepts to Improve Your Non-Functional Requirements Whitepaper

can document these stakeholders’ input in a central location for multiple teams to reference and update. It’s an easy, powerful way to help them get to the right people early.

• Non-functional requirements categories are common. Do the categories that are laid out in The Quest for Software Requirements resonate? You might change verbiage or categories to fit your organization, but most companies developing software care about these requirement types. Commonalities mean you can tailor categories and definitions for your company, and teams can use a standard catalog across projects. They can pick those that are relevant to their project, minimizing the risk of missed requirements.

• Elicitation questions are also common. Because non-functional requirements types are common across projects, business analysts ask similar questions to define them. For example: “How many users does the system need to support simultaneously?” and “What hours does the system need to be available?” are common questions to elicit performance and availability requirements. By developing a standard set of potential elicitation questions for each category, Business Analysts don’t start with a blank piece of paper. They can choose the best questions for their purpose, accelerating requirements definition on every project.

• The requirements themselves can be common. Many non-functional requirements are global, applying to all systems within your company. For example, if your organization has internal authentication standards, user login requirements should be the same across every internal application. Your organization can define standard requirements once and refer to them multiple times, reusing them to improve quality, consistency, and speed.

These commonalities mean you can predefine a lot of what a Business Analyst or Product Owner will need to define top-notch non-functional requirements, regardless of the project, business unit, or systems involved. It means improving non-functional requirements’ quality and the speed with which they’re delivered may be easier than you expected.

4 Concepts to Improve Your Non-Functional Requirements

Smart leaders are helping their teams improve non-functional requirements so their products better meet customer expectations. To help your team do the same, execute to improve on these 4 key concepts:

1. Predefinition to Deliver Better and Faster

Based on commonalities across projects in your organization, predefine the following requirements artifacts and store them centrally for all projects to leverage:

• Stakeholder definition. Create a standard set of non-functional requirements stakeholder profiles and the people that fill those roles in your organization.

• Non-functional requirements categories. Refine the categories and definitions in “The Quest for Software Requirements” or use information from past projects to develop a standard catalog that all teams can reference.

• Elicitation questions. “The Quest for Software Requirements” also provides a comprehensive set of questions for each requirements category. Review and refine them to align with your organization’s needs and verbiage. Alternatively, take elicitation questions from successful past

Your organization can define standard requirements once and refer to them multiple times, reusing them to improve quality, consistency, and speed.

6blueprintsys.com

4 Concepts to Improve Your Non-Functional Requirements Whitepaper

projects to start your own set of questions from which business analysts can choose.

• Standard sets of requirements. Review current standards for global non-functional requirements, like those related to performance, availability, backups, usability, security, and compliance. Create a searchable catalog of them for all teams to reference.

2. Defined Process to Improve Coverage

Lay out an explicit non-functional requirements definition process as part of your standard product development methodologies. At a high level, it should look something like this:

1. Perform stakeholder identification by reviewing predefined stakeholder profiles and people.

2. Build visuals – like process flows or system context diagrams – to help describe the environment.

3. Review your predefined catalog of non-functional requirements categories and identify areas that may need elicitation.

4. Review your predefined catalog of elicitation questions to create interview documentation.

5. Hold elicitation sessions with stakeholders and record the responses.

6. Define the non-functional requirements in your requirements documentation or tool.

7. Validate the non-functional requirements with stakeholders and refine them.

Whether your teams are Waterfall or Agile, they need to perform these tasks. The order in which they occur or the cadence may differ as will the method used to document and validate non-functional requirements, but each step is important. Defining it explicitly (along with providing needed education and coaching) means teams can’t ignore these critical requirements.

3. Robust Analysis to Boost Understanding

Strong analytical capabilities are critical for defining and managing all requirements. They help teams get them right, reduce duplication of efforts, and improve requirements management capabilities. Visual models and traceability are key enablers of the kind of analysis business analysts need to deliver today.

• The case for visual modeling. Visual models help project teams and stakeholders have deeper conversations that lead to better requirements. They also help analysts assess the impact of change. Teams are increasingly using business process models, in particular, to improve understanding. They enable teams to identify key performance indicators related to simultaneous users executing a particular step, the length of time a step should take, or the time elapsed between steps.

• The case for traceability. Establishing traceability between non-functional requirements and related artifacts like process steps, risks, stakeholders, and other requirements provides teams with a powerful analysis tool to define stronger requirements and assess the impact of change. Traceability between requirements and business goals helps them focus on delivering requirements targeted to business value.

If your teams aren’t developing visual models and establishing traceability between artifacts, they’re limited in the breadth and depth of analysis they can do. Provide them with the skills they need to execute these critical capabilities, and invest in tools to support them.

Visual models and traceability are key enablers of the kind of analysis business analysts need to deliver today.

Blueprint provides an industry-leading software solution that helps large organizations build better business and software applications. Enterprises across the globe use Blueprint to ensure regulatory compliance, speed transition to Agile, better align Business and IT and leverage seamless integration with leading ALM technologies. Nearly half of all Fortune 100 companies choose Blueprint to de-risk and accelerate their software projects.

© 2016 Blueprint Software, Inc. All rights reserved. All product and company names and marks mentioned in this document are the property of their respective owners.

90 Eglinton Ave E #700 Toronto, ON M4P 2Y3, Canada

1.866.979.BLUE(2583) www.blueprintsys.com

7BP281881 27-Mar-2016

4 Concepts to Improve Your Non-Functional Requirements Whitepaper

4. Centralization to Improve Quality and Collaboration

Centralization and document management is key for teams to reuse standard artifacts like requirements categories, elicitation questions, and standard requirements. They need to always work with the latest information – ideally referencing centralized artifacts (versus copying), so as changes occur, they trickle down.

Centralization is also a key enabler of collaboration, which improves the quality of requirements and the speed with which they can be defined. Developing quality software products is a team effort, and today’s teams are often large and distributed. They need robust, creative ways to collaborate, so they can move quickly. As you consider enterprise requirements tools and techniques, make sure that centralization is a primary consideration.

How Blueprint Can Help

Blueprint recognizes the importance of non-functional requirements in delivering products that meet customer expectations. We have partnered with Roxanne Miller, author of “The Quest for Software Requirements” to develop a Non-Functional Requirements Accelerator that provides a catalog of more than 2,000 elicitation questions for non-functional requirements in 14 categories. The Accelerator’s list of predefined categories helps business analysts think about elicitation questions in buckets, and the lists of predefined questions within each category speed up interview design and improve requirements coverage. The benefits can be massive in productivity and software quality.

Blueprint’s reuse capability allows organizations to reduce duplication of effort, enhance team collaboration, and improve project accuracy by centralizing the elicitation questions, recorded response provided to those questions, and the non-functional requirements themselves. This allows project teams to reuse pre-defined non-functional requirements for their Waterfall BRDs, or include those standards from the acceptance criteria of user stories and Definition of Done on Agile projects.

Blueprint also supports visual modeling and complex multi-directional traceability to accelerate elicitation and improve analysis.

For more information on how Blueprint can help improve critical non-functional requirements, please contact us today for more information.