Correcting Non-Functional Myopia in Business Analysis

Myopia, or nearsightedness, is an eye condition resulting in distant objects being rendered blurry in the field of vision. So, what does this have to do with business analysis you may be wondering. The Merriam-Webster Dictionary defines myopia as “a lack of foresight or discernment, a narrow view of something” (definition #2). Being myopic is diametrically opposed to any sound practice of business analysis. In this fast-paced, emergent world, we must possess clear vision so we can steer our solution away from the obvious, clearly visible obstacles in the form of organizational failures that culminate in a negative impact on stock price, revenue, market share, or reputation.

 

In this article, we will focus our lens on a prevalent issue and develop a strategy for dealing with the inherent risk. 

 

A Guide to the Business Analysis Body of Knowledge® (BABOK® Guide v3) describes non-functional requirements as requirements that “do not relate directly to the behaviour of functionality of the solution, but rather describe conditions under which a solution must remain effective or qualities that a solution must have” (p. 16).  Did you know that approximately 90 percent of an iceberg lies below the water line?  Figuratively speaking, non-functional requirements can also be said to exist below the surface.  As business analysts, we must nimbly move horizontally (breadth) and vertically (depth) to perform sufficient due diligence on all solution requirements.  Simply stated, like the size of an iceberg cannot be seen above the water, as a business analyst you must elicit and analyze the non-functional requirements (below the surface) to understand the impact on the functional requirements.  Becoming multi-faceted in our approach is essential for value realization and a high-performance rating of the deployed solution. 

To meet this challenge, we must be savvy when discussing requirement attributes with both business and technology stakeholders.  We must also be similarly thoughtful and analytical with processes, people, and technologies to ensure a reliable and sustainable solution underpins a positive user experience.  With curiosity and courage by our sides, we will be able to blaze new trails and successfully tackle our challenges while delivering value to our stakeholders.  Embracing uncertainty in our mind and flexibility in our interactions will enable us to be responsive to the pressing demands of our fluid environment. 

Myopia or narrowmindedness in a production environment is exemplified by the inability of a system to conform to a quality attribute such as availability, performance, reliability, security, and usability. The most common symptoms are dissatisfied customers who often express their sentiments on social media, news stories covered by the media and other outlets discussing the failure, and significant resources expended by the affected organization repairing the problem. Any one symptom or a combination of symptoms can have significant ramifications in the short-term and extend over the long-term.

 

But before we dive deeper, we will look at a real-world example to reinforce the important role that non-functional requirements play in the solution design process.

 

The U.S. Government Accountability Office (GAO) published a ‘Report to Congressional Requesters’ (GAO-15-238) on March 4, 2015 regarding the investigation into the problematic deployment of Healthcare.gov on October 1, 2013. GAO-15-238 (p. 14) documents one of the key findings: “Systems supporting Healthcare.gov were initially launched without adequate capacity to accommodate the number of visitors to the website. In particular, when the system was launched on October 1, 2013, the Enterprise Identity Management system was overwhelmed by the number of users attempting to create accounts-nearly half a million in the first 2-and-a-half weeks of open enrollment-preventing the system from functioning as intended.” Within the context of non-functional requirements, GAO-15-238 (p. 27) states: “nearly 48 percent of all the functional requirements for the FFM system’s eligibility and enrollment module were missing the required associated dependencies for business activities and system requirements”.

Research the Non-Functional and Functional Condition

While you have seen above the importance of considering any and all symptoms, you must also understand the logical constraints and implications between activities and their associated dependencies on your project. From BABOK® v3, we learned that non-functional requirements are “usually measurable and act as constraints on the design of a solution as a whole” (p. 448). In contrast, a functional requirement is defined as “a capability that a solution must have in terms of the behaviour and information the solution will manage” (p. 446). A common example of a non-functional requirement is system availability during core business hours: e.g., ‘the system must be available 100% of the time from 6:00 AM EST to 6:00 PM EST, Monday through Friday, excluding corporate holidays.’

 

At the solution level, the aggregated constraints must also be considered and balanced appropriately across the known set of functional requirements and non-functional requirements based on the requirements architecture. BABOK® v3 (p. 304) states: “Determining the optimal portfolio of non-functional requirements in a given organizational context is central to delivering value to stakeholders. The assessment of a non-functional requirement, such as localization or maintainability, may impose contextual pressures on other non-functional requirements. Context is dynamic by nature and non-functional requirements may need to be adjusted or removed outright.” Contextualizing non-functional requirements is integral to managing risk and optimizing performance.

Figure 1: Non-Functional Requirements Balancing 

Ambiguity most often surrounds non-functional requirements; however, we must quantify the non-functional requirement to an acceptable level.  BABOK® v3 (p. 304) states: “Including an appropriate measure of success provides the opportunity for verification.  For example, ‘The system must respond quickly’ can be expressed as ‘The system must provide 90% of responses in no more than two seconds’”.  You cannot build a house without a tape measure and a multitude of measurements, so you should not build a solution without a mechanism to measure performance at different times throughout the solution life cycle.  Defining metrics to measure the performance of a solution is essential to sound design and value realization. 

Talk to an Eye Care Professional 

It is now time for you to consult BABOK® v3, which contains generally accepted practices in the form of technical knowledge and practical guidance. The best tool at your disposal is the Non-Functional Requirements Analysis (10.30) technique (pp. 302 - 305).  This technique is described in a comprehensive manner and is mapped to the Specify and Model Requirements (7.1) task per the Requirements Analysis and Design Definition knowledge area and is also mapped to the Measure Solution Performance (8.1) task per the Solution Evaluation knowledge area (p. 467).  Special attention needs to be paid to any impact to scope, time, or cost. 

 

A prerequisite to the Non-Functional Requirements Analysis technique is collaborating with information technology owners across the different functional areas (e.g., architecture, development, security), in addition to the business and end users. Engaging with and eliciting non-functional requirements from technology professionals will give them a voice in the process and will provide you with the perspective you need to define the measures and constraints from a non-functional requirement perspective. 

 

Common techniques to support the Conduct Elicitation (4.2) task per the Elicitation and Collaboration knowledge area include: brainstorming (10.5), document analysis (10.18), interviews (10.25), and workshops (10.50) (pp. 63 - 64).  Tailoring your approach to people, processes, and tools across project and operational environments will strengthen user adoption and enable a feedback mechanism for solution optimization. 

 

By linking key outputs across the associated knowledge areas in context of non-functional requirements analysis, this hierarchy facilitates the understanding of how elicitation results should begin and progress throughout the requirements analysis activities.  Additional details surrounding the design definition activities are not included to maintain the spotlight on the requirement details.  A description of each knowledge area output is also provided to further define the importance and relationship.  A simple way to remember the distinction between verification and validation is to ask the following questions: are we building the product right? (verification) and are we building the right product? (validation) (Verification vs Validation article). 

 

Figure 2: Non-Functional Requirements Analysis Outputs 

 

Knowledge Area Output	Description
4.2, 4.3 Elicitation Results (any state)	“unconfirmed: captured information in a format that is specific to the elicitation activity” (BABOK® v3, p. 65).  “confirmed: integrated output that the business analyst and other stakeholders agree correctly reflects captured information and confirms that it is relevant and useful as an input to further work” (BABOK® v3, p. 67).
7.4 Requirements Architecture	“the requirements and the interrelationships among them, as well as any contextual information that is recorded” (BABOK® v3, p. 152).
7.1 Requirements (specified and modelled)	“any combination of requirements and/or designs in the form of text, matrices, and diagrams” (BABOK® v3, p. 141).
7.2 Requirements (verified)	“a set of requirements or designs that is of sufficient quality to be used as a basis for further work” (BABOK® v3, p. 144).
5.5 Requirements (approved)	“requirements which are agreed to by stakeholders and are ready for use in subsequent business analysis efforts” (BABOK® v3, p. 98).
7.3 Requirements (validated)	“validated requirements and designs are those that can be demonstrated to deliver benefit to stakeholders and align with the business goals and objectives of the change.  If a requirement or design cannot be validated, it either does not benefit the organization, does not fall within the solution scope, or both” (BABOK® v3, p. 147).
7.5 Define Design Options	“describe various ways to satisfy one or more needs in a context.  They may include solution approach, potential improvement opportunities provided by the option, and the components that define the option” (BABOK® v3, p. 156).

 

Take an Eye Exam

Supplementing your knowledge from other disciplines is typically necessary to develop a mature perspective of the topic being researched.  By leveraging key concepts from the IT service management (ITSM) framework known as ITIL, we can use the value formula to stress the importance of non-functional requirements.  The components of the formula are mutually inclusive and underscore the importance of focusing on how the service or solution will operate.  Value is only created once the warranty has been properly specified and joined to the utility. 

Figure 3: Value Formula 

 

utility (fit for purpose) + warranty (fit for use) = value created 

expressed as: features + measures and constraints = optimal solution 

 

Utility is defined as “the functionality offered by a product or service to meet a particular need.  Utility can be summarized as ‘what the service does’ and can be used to determine whether a service is ‘fit for purpose’” (ITIL® Glossary of Terms English v.1.0, p. 65).  Warranty is defined as “assurance that a product or service will meet agreed requirements.  Warranty refers to the ability of a service to be available when needed, to provide the required capacity, and to provide the required reliability in terms of continuity and security.  Warranty can be summarized as ‘how the service is delivered’ and can be used to determine whether a service is ‘fit for use’” (ITIL® Glossary of Terms English v.1.0, p. 66).  We must test the functionality against the specified utility and warranty in order to ascertain whether myopia exists. 

 

Get a Prescription 

One of the best ways to assure quality is to employ a simple checklist containing the non-functional requirements categories as defined in BABOK® v3 (p. 303). In addition to a checklist, adding these categories with a brief description to a traditional requirements document or electronically via a requirements life cycle management tool will provide the necessary process and audit trail required to support the proper definition and management of non-functional requirements.  Simply seeing a category will jog your memory and remind you to analyze the non-functional requirement using a specific filter.  In an agile analysis framework, you may add separate user stories to the product backlog.  The checklist is not exhaustive and should be adapted to your specific situation. 

 

Non-Functional Requirements Categories 

 

Availability 

Certification 

Compatibility 

Compliance 

Extensibility 

Functionality 

Localization 

Maintainability 

Performance Efficiency 

Portability 

Reliability 

Scalability 

Security 

Service Level Agreements 

Usability 

 

Under the heading of Verify Requirements, BABOK® v3 (p. 142) states: “The most important characteristic of quality requirements and designs is fitness for use”.  They must meet the needs of stakeholders who will use them for a particular purpose.  Quality is ultimately determined by stakeholders.”  Fitness for use is another way of expressing warranty in an operational context.  As with any type of requirement, it is imperative for non-functional requirements to contain quality characteristics as defined in BABOK® v3 (p. 143).  Analogous to a blacksmith forging a new implement in the shop, we must likewise rely on our unique artisanal abilities to handcraft a durable solution that can withstand the pressures exerted on it in the field.  These quality characteristics should be tested to assure the results meet the agreed level of quality defined by the team. 

 

Characteristics of Requirements Quality 

Atomic 

Complete 

Concise 

Consistent 

Feasible 

Prioritized 

Testable 

Unambiguous 

Understandable 

Get Fitted for Glasses 

President Ronald Reagan once said: “trust but verify”.  This adage applies to the world of software testing in the form of inspecting deliverables and testing products.  Adopting a risk-based testing approach for non-functional testing is crucial to the overall success of the solution in the operational environment.  Some common types of non-functional testing include security and performance testing.  As with any type of requirement, the testability and traceability attributes are important factors for effectively designing tests to prove the system behaves as expected.  These tests should be designed as early in the product development life cycle as possible because early detection is key.  A critical success factor of adopting a thoughtful design approach will ultimately reduce technical debt in the application landscape and enable a resilient infrastructure. 

 

The International Software Testing Qualifications Board (ISTQB®) manages different levels of software testing knowledge, and the Advanced Level Syllabus for the Technical Test Analyst contains in-depth information on non-functional testing in section ‘4. Quality Characteristics for Technical Testing’ (Technical Test Analyst Syllabus, pp. 25 - 36).  Details are provided for security testing, reliability testing, performance testing, maintainability testing, and portability testing.  Defining the test environments, acquiring the tools, and allocating the resources are essential to the technical test effort.  The costs associated with quality are important factors that must be balanced when defining the test strategy and test plan and are directly linked to risk mitigation strategies. 

 

The International Organization for Standardization (ISO®) maintains a quality standard named ‘Systems and software Quality Requirements and Evaluation (SQuaRE)’.  This standard defines a quality in use model and a product quality model that “provide a set of quality characteristics against which stated quality requirements can be compared for completeness.  The scope of application of the quality models includes supporting specification and evaluation of software and software-intensive computer systems from different perspectives by those associated with their acquisition, requirements, development, use, evaluation, support, maintenance, quality assurance and control, and audit” (ISO/IEC 25010:2011 standard).  The quality characteristics are covered by the non-functional requirements categories covered in BABOK® v3; however, the overall standard provides complementary guidance from a quality perspective. 

 

Wear your Glasses 

Wherever you are on the product development continuum (predictive versus adaptive), and no matter what template or mechanism you use, harness the power of both sides of your brain as you continue your requirements and design journey.  The non-functional requirements analysis technique applies to the Agile, Business Intelligence, Information Technology, Business Architecture, and Business Process Management perspectives.  If you are in an agile context, then write down your non-functional requirements as a user story.  If you create use cases, then add a non-functional requirement section to each specific use case.  If you are constrained by time, then add the non-functional requirements to the product backlog using the Backlog Management technique (10.2) as defined in BABOK® v3 (pp. 220 - 223). 

 

As a society, we are on the cusp of the next wave of technological advances in the fields of Artificial Intelligence (AI) and the Internet of Things (IoT).  Organizations around the world are harnessing the power of big data across connected devices in conjunction with machine learning to provide innovative products such as self-driving cars, learning thermostats, and digital personal assistants.  Since innovative solutions tend to have a significant investment in the information technology infrastructure, non-functional requirements should be incorporated early in the development process resulting in a reduction in the myopic condition.  As with any product or service, the non-functional characteristics of a solution will need to be thoroughly verified and validated prior to deployment. 

 

Embracing a 360-degree view of a requirement and the broader solution scope will ultimately ensure operational success of the supported solution and will correct the non-functional myopia that has plagued past projects.  By actively listening and engaging with all our stakeholders, and by relying on our collective wisdom and individual curiosity, our stakeholders will realize value from the clarity (20/20 vision) we gain as business analysis professionals.  With your new glasses you can  clearly see non-functional requirements, and you  can safely keep your eyes on the road ahead.  You will gain confidence as you begin to see the full picture in vivid detail while building a rapport with your cross-functional teammates that will pay dividends in the future. 

Page Break 

References 

A Guide to the Business Analysis Body of Knowledge® (BABOK® v3) 

©2005, 2006, 2008, 2009, 2015 International Institute of Business Analysis.  All rights reserved. 

pages 16, 63 - 65, 67, 98, 141 - 144, 147, 152, 156, 220 - 223, 302 - 305, 446, 448, 467 

 

ISO/IEC 25010:2011 Page 

© 2018 International Organization for Standardization 

no page (ISO/IEC 25010:2011 standard) 

https://www.iso.org/standard/35733.html 

 

ITIL® Glossary of Terms English v.1.0 

© AXELOS Limited 2011 

pages 65 (utility), 66 (warranty) 

https://www.axelos.com/Corporate/media/Files/Glossaries/ITIL_2011_Glossary_GB-v1-0.pdf 

 

Merriam-Webster Dictionary 

© 2018 Merriam-Webster, Incorporated 

no page (myopia, definition #2) 

https://www.merriam-webster.com/dictionary/myopia 

 

Report to Congressional Requesters (GAO-15-238) 

U.S. Government Accountability Office (GAO) 

pages 14, 27 

https://www.gao.gov/assets/670/668834.pdf 

 

Technical Test Analyst Syllabus 

© International Software Testing Qualifications Board 

pages 25 - 36 

https://www.istqb.org/downloads/send/10-advanced-level-syllabus-2012/55-advanced-level-syllabus-2012-technical-test-analyst.html 

 

Verification vs Validation Page 

© 2018 Software Testing Fundamentals 

no page (Verification vs Validation article) 

http://softwaretestingfundamentals.com/verification-vs-validation/ 

 

Image 

Myopia in Madrid Stock Image (Credit: Mario Guti) 

© 2018 iStockphoto LP.  The iStock design is a trademark of iStockphoto LP. 

stock photo ID: 667396944 

https://www.istockphoto.com/photo/myopia-in-madrid-gm667396944-121805929 

Page Break 

Summary 

The Correcting Non-Functional Myopia article was born out of a need to address recurring solution gaps I experienced over a span of twenty years.  Practical guidance is provided using the theme of myopia (nearsightedness) to address the “eye condition” from a best practice perspective.  Regardless of the reader’s experience level with defining and managing non-functional requirements, the practitioner can tailor and apply the expertise to any project or operational initiative resulting in a more comprehensive and usable solution. 

 

Information 

Correcting Non-Functional Myopia in Business Analysis, © 2019 John B. Reeves, CCBA.  Peer Reviewed by Adewale Alafia and Colleen Cristarella.  Last Saved on October 25, 2019 using Microsoft® Word (Correcting Non-Functional Myopia in Business Analysis.docx, < # > pages, 3,103 words).