| 3.2 Enterprise Risk Requirements |  |
Build better applications.
Learn to analyze and design for enterprise risk requirements as a part of the capability development for citizen developers.
In this section you will find:
•A definition of what functional and nonfunctional requirements are
•Indications on how to define, classify, and recognize nonfunctional requirements in application design
•The role of stakeholders when gathering requirements
“If you can't describe what you are doing as a process, you don't know what you're doing.”
W. Edwards Deming
Overview
Requirements define what the application should be able to do, how it should work, and how the user will interact with it. They also specify the underlying technologies, architectural landscape, and potential future usage.
Functional requirements (FRs) describe what the application should do, whereas nonfunctional requirements (NFRs) are about the quality of the application and its delivery. These can be of a technical or organizational nature.
Requirements have stakeholders as their owners, and because stakeholders have different levels of interest in the application, it is important to stay in close contact with them.
In this section, special attention is given to NFRs as it is important that these are designed into an application to protect enterprise risk. NFRs are not obvious and it is easy to overlook them, especially if you haven't been trained to spot them. Without gathering such requirements, citizen developers run the risk of building something that is insecure and poorly optimized, leading to lag, high latency, a subpar user experience, time-consuming maintenance, and an inability to scale.
It doesn't matter if the citizen developer is the only one using the application. The application will be part of a wider ecosystem; therefore, it will need to comply with certain rules and regulations. Before publishing the application into the operational environment, it needs to be added to the service catalog (see Section 6.5). In order to get the application into the catalog, the design will need to have fulfilled the nonfunctional requirements.
 | MARKET RESEARCH |
PMI's Pulse of the Profession® research has shown that poor requirements management is a major cause of project failure. For every dollar spent on projects and programs, 5.1% is wasted due to poor requirements management (Project Management Institute, 2014).
Enterprise Risk Requirements in Practice
Let's assume you have a great idea to build an application that will address a well-known gap in your organization and you already know that it will be used by many eager colleagues once it goes live. The application needs to meet certain requirements in order to satisfy users and get their buy-in; and you, as the idea originator, probably already have a lot of them in mind. But as application development gets underway, other requirements will come into play. If you are lucky, these will be functionality requests or changes that serve to introduce new and desirable features to the application. Less desirable changes fall into maintenance and performance categories, as these could point to underlying structural issues that may be difficult to remedy without a significant rebuild effort.
An effective way to minimize disruptive development work on an application, once it is already live, is to make sure you spend enough time and focus on capturing requirements early; in particular, the nonfunctional ones.
Stakeholders
A stakeholder in this context can be defined as a person, group, or organization that has an interest in, or will be affected by, the application being developed.
Stakeholders comprise a wider group than the users alone. So how can citizen developers find them all? There are multiple theories about how to identify and manage stakeholders and there are pros and cons for each. The theory in this book is limited to a simple and usable method for identifying them and relating them to specific requirements.
Stakeholders can be classified into three broad types:
1. Business stakeholders
Business stakeholders are directly affected by and have a direct interest in the functionality and the workings of the application. They usually are the ones providing requirements regarding what the application should do and how it should work. Users are clear examples of business stakeholders.
2. Enterprise stakeholders
Enterprise stakeholders are part of the organization, but are not directly affected by the application. They do, however, have an interest in the application because they do not want it to interfere with their goals and constraints. To prevent that, enterprise stakeholders should be enabled to formulate their requirements. The IT department and the chief information security officer are examples of enterprise stakeholders.
3. Environmental stakeholders
Environmental stakeholders are, most of the time, completely unaware of the application's existence until it conflicts with their constraints and processes. Requirements from this group are mostly derived from rules and regulations that have been put in place in a wider sense than the organization alone. Governmental and regulatory organizations are examples of environmental stakeholders.
Requirements
For the purposes of this section, a requirement can be defined as a singular, documented, functional, or nonfunctional need that the application aims to satisfy.
Functional requirements describe what the application should be able to do (i.e., how the application should function). Examples are: What part of which process needs automation (workflow), what data should be processed and how (business rules), and what output must be generated and when (reporting)?
Nonfunctional requirements address quality (i.e., how the application should work and be worked with). These requirements can be of a technical nature, such as response times (performance) or data modeling constraints (data integrity), but they can also address an organizational aspect, such as where to store the data (regulatory), how to report bugs (serviceability), or to what level users should be trained (usability).
The likelihood of requirements being provided by the different types of stakeholders is illustrated in Table 5.
Gathering and analyzing functional requirements
Creating applications using a citizen development application platform involves a level of documentation. The documentation required is dependent upon the complexity of the application, but as a general rule, documentation should be kept light to promote creative and intuitive design thinking. That said, all application development benefits from using a structured approach. Users and business owners usually own most of the functional requirements and use them as acceptance criteria to decide if the solution has been satisfactorily delivered.
To gather functional requirements, the citizen development squad needs to be in close contact with relevant stakeholders. The stakeholders will help to identify what the requirements are, but will also be able to answer “why.” Why do they need the requirement to be implemented? What issue will it solve or what opportunity is gained? Without knowing the why, there is no way of telling if the requirement will solve the business problem at hand.
Let's imagine an application we want to build: an events management app that will make our work much more productive when it comes to finding, scheduling, and attending events. Currently, the team takes requests from across the business to set up events and then emails them using mailing lists. It's decided that this is too time consuming, and a new application should be created to allow colleagues to schedule and organize events directly; then once approved, the events will be instantly shared with people across the organization.
Usually, in the first phase of gathering and analysis, a requirement describes part of a process that the application will automate. In the events management example, this could be “registering a new event” or “sending an invitation to all participants.” If we move one layer deeper, more concise requirements appear, such as “sending a confirmation message by mail after registering the event” or “using email to send the invitation.”
In the second phase, it is important to ask “what if” questions. What if someone enters an event that already has been registered? What if no email address is available?
First, we look at the so-called sunny-day scenario: how the application should work in the most ideal of circumstances. Next, we address the rainy-day scenario: What if circumstances are not ideal? How should the application respond?
There are multiple techniques available for doing this, like software requirements specification (SRS), use casing, or user stories. Choose whichever method fits your need and that of the organization. Just be sure to document requirements in a concise way and share them with your stakeholders. By doing so, everyone involved will have the same picture of what is being built, and you will be able to jointly determine whether or not the project is ready to go live.
 | DEFINITION |
Software requirements
A field within software engineering that deals with establishing the needs of stakeholders that are to be solved by software (“Software Requirements,” 2020).
Software requirements specification (SRS)
A description of a software system to be developed. The SRS document lists sufficient and necessary requirements for the project development (“Software Requirements Specification,” 2020).
It is not uncommon for functional requirements to change during the project and for requirements to be added or removed. As the project progresses, new insights might be reason to review the requirements and make other choices. This is not a problem if the requirements are documented and managed within the project because everyone involved still knows or is able to determine what has been changed and why.
Nonfunctional requirements (NFRs)
NFRs are just as important as functional requirements because, aside from the functionality, the application needs to be fast and accessible from a variety of devices and operating systems. It will most likely need to be accessible on different devices on different operating systems, too. As in the events management application example, event organizers and attendees need to be able to share content associated with an event—a functional requirement—but this would suggest that storage and capacity need to be factored in. These kinds of requirements are easily missed unless you have been trained to spot them. That is why this book gives extra attention to NFRs.
NFRs can be provided by business stakeholders; however, most of the time, the idea originators ask for them first. Enterprise stakeholders are the bulk supplier of NFRs, as they want the application to fit well into the enterprise landscape. In larger organizations, these requirements can be derived from internal documentation, e.g., an enterprise master data model or an employee code of conduct. Whatever the source, it is important to also include the stakeholders themselves.
The environmental stakeholders have requirements that, in most cases, can be derived from documentation, such as law books and regulatory publications. Besides governmental agencies, there are other bodies that may be considered to be environmental stakeholders. Think of unions, quality assurance agencies (ISO, ISAE, etc.), and also private entities that the organization has a relationship with.
In a broad sense, nonfunctional requirements can be thought of as falling into two broad types:
•Regulatory and compliance
•Quality
Regulatory and compliance nonfunctional requirements
Regulatory and compliance NFRs are external or internal constraints. Internal constraints take the form of an organization's policies (e.g., policies owned by enterprise stakeholders). External constraints are government regulations, industry standards, and compliance or other macro parameters set by environmental stakeholders that an organization must adhere to in order to continue operating (e.g., data laws like the General Data Protection Regulation (GDPR) or International Financial Reporting Standards [IFRS]).
| DEFINITION |
General Data Protection Regulation—for non-EU
This is a regulation in EU law on data protection and privacy in the European Union and the European Economic Area; it also addresses the transfer of personal data outside the EU and EEA areas (“General Data Protection Regulation,” 2020).
Quality nonfunctional requirements
Quality nonfunctional requirements are related to the business or user demands about the quality of the application (e.g., availability or performance). These requirements are not always easy to identify, but often become apparent once an application is already live and struggling to deliver an acceptable user experience or outcome. Qualities are always about choice, regardless of the demand. For instance, you could choose to accept low performance temporarily, if you would prefer to have a swift deployment.
Quality NFRs fall into several categories. Not all will be relevant to your application, but as a matter of habit, it is a good idea to give due consideration to all of these in the early stages of designing your application (Table 6).
In order to carry out a good evaluation of NFRs, citizen developers should use the following tool (Tool 6).
Identifying and determining the relevant nonfunctional requirements
Regulatory and compliance-type NRFs can be prepopulated (and, in a mature organization, usually will), as these are quite rigid and unlikely to change often. Start by consulting with the IT and compliance departments or citizen developer competency center about them. Make sure to align them early in the process.
However, since it is likely that applications will bring new functionality and data elements into the organization, citizen developers also need to consider if the prepopulated set of requirements is complete or if new elements should be added. It is best practice to also validate this with the IT and compliance departments.
Quality requirements are, by and large, specified by the business stakeholders, but citizen developers must actively seek them out since business stakeholders often aren't intuitively aware of these types of requirements.
Tool 7 provides a quick checklist that citizen developers can use to make sure they are considering the most important NFRs. This list is not intended to be exhaustive. There are other NFRs that may need to be considered depending on the type of application being built. It is best to build this table in concert with the relevant departments, so it can be used throughout the organization. Alternatively, the organization may have already developed a nonfunctional design tool that citizen developers can use to guide their thinking during the design.
Nonfunctional requirements assessment template
Within an organization, there can be several degrees of emphasis in NFRs depending on the important aspects. For that, we recommend using this template (Tool 7) and customizing it to best suit the organization's needs. It can help to bring awareness to IT, and some NFRs can be prepopulated by IT. They may even give it to the business for its completion.
