Impact of Non-Functional Requirements on Software Systems

One of the most important roles for an architects is in the requirements engineering phase; this is how architects help define the solution that best satisfies all stakeholders. Ranju Saroch

Requirement and Constraint Analysis

Consider these three anecdotes from the article Requirements and Innovation by Ruth Malan (Malan 2007): When Dean Kamen (yes, the inventor of medical devices and also the Segway) asked "where you would put a third eye if you could have one?" everyone said on the back of their head; without hesitation, generally, on the back of the head. But when Dean said, "what about on the tip of your finger?" everyone agreed, without hesitation, that that was much better! Henry Ford reportedly said If I had asked people what they wanted, they would have said faster horses." TWA asked Douglas Aircraft Corporation to produce an aircraft with three engines. When Douglas engineers probed for the reason for this "requirement," they found that the desire was to be able to fly safely even if one engine was disabled (this was in the 1930's when engines were not so reliable). Douglas produced the DC-1 with 2 engines, and proved that it could safely fly with just one engine, taking off from Albuquerque, NM and flying safely to Winslow, AZ. Only one DC-1 was built, but it was the forerunner to the DC-3, which helped make air travel popular and economically viable. The above anecdotes show the role an architect can play in innovation by recognizing the underlining hidden assumptions and feasibility of alternate approaches. In order to do this, the architect needs to have direct contact with users and stakeholders. It has been found that many software systems fail or are not able to satisfy the requirements of all the stakeholders involved due to inadequate non-functional requirements (Malan, Bredemeyer 2002). Functional Requirements are important as they define the features of the system, but the system will be useless if it is not able to work in the real world. I did not realize the degree to which this was true until I faced this problem myself on a project at Datum Corporation. I had just started working as a software architect, and was assigned to a project for which requirements had already been completely drafted by an external business analyst. The

customer was very happy with that consultants work and assured me that the business analyst had captured all of their intentions and needs. Datum wanted to build a management information system (MIS) which would not only satisfy the current user requirements, but also provide the basis for quickly developing future applications. Months were spent in designing this application. As demonstration and release dates drew closer, the team began to panic. Design and code reviews were being scuttled, and more developers were added to the project to meet the deadline for the first demo. The first demo did arrive, and the users liked what they saw. However, they surprised the demo team when they immediately started making additional demands. They asked for validation functionality to be built in, which was never captured in the original requirements. They also asked for restricted access to certain fields on a particular form, based on user type. Afterward, an architecture assessment revealed that some of the new requirements like user security, validation, and so on, could not be met by the current architecture without significant rework. Designs started degenerating and quality problems started to creep in. The project schedule was changed, and the team worked day and night to rewrite the code to include the new changes. Finally, the application was released. The application met the critical customer requirements but failed to meet the organizations goal of developing future application quickly with minimal maintenance. Also, the customer was not happy as one of their functional requirements for opening reports in Word format was never captured in the original requirements phase. Also. compared to the original estimates, the application development cost had increased significantly. Furthermore, application maintenance had became a nightmare; even adding small features took lot more time than we had originally planned, and sometimes required significant rework. Many architects have faced these types of issues. Looking back, I feel the lack of documenting and tracking non-functional requirements made it hard to prioritize and make trade-offs between the quality of the system and the cost to develop and enhance it. In my case, the lack of documentation of the different user types, access criteria, and report output format had a direct impact on the design and the quality. This in turn had a negative impact on maintenance processes and cost. Still, most organizations have created a separation between Requirements and Design phases. These organizations use their Requirements phase to address business problems, while they use their Design phase to address the solution to those problems. Current requirements engineering approaches are mainly used to gather functional requirement (FR) which capture the intended behavior of the system, but fail to gather the non-functional requirement (NFR) which impose constraints on the product/application being developed. Due to the lack of NFR, requirements are not mapped directly and explicitly from requirements engineering to the architectural design phase. Moreover, requirements omission are often detected very late in the process and result in significant

rework, which increase the cost of applications and affect the quality of systems, even to the point of failure. From my experience, I realized that the architect is accountable for the system being good, right and successful. Therefore, an architect should be involved in the development of requirements in order to help them create a design that achieves a compelling user experience, thereby making decisions that will have huge consequences for the life cycle of the system that best satisfies all stakeholders. This does not mean that the architect needs to do all the requirements work, but the architect needs to be involved and have direct contact with stakeholders. An architect needs access to business management in order to understand the strategic direction and lifecycle cost goals for the system. They also need to understand the users goals and requirements in order to make sense of the context into which the system will fit.

Difference between Functional And Non-Functional Requirements

Requirements are partitioned into functional requirements (FR) and non-functional requirements (NFR). Functional requirements are associated with specific functions, tasks, features or behaviors the system must support, while non-functional requirements are constraints on various attributes of these functions or tasks. Non-functional requirements tend to be stated in terms of constraints and qualities on the results of tasks that are given as functional requirements (e.g., constraints on the speed or efficiency of a given task). Qualities are properties or characteristics of the system like maintainability, reliability, and usability that its stakeholders care about and hence will affect the degree of satisfaction with the system. Constraints are characteristics of the whole environment within which the application or product will integrate. For example, one constraint could be the skill set of available developers in the case of a development organization, while another could be the target operating system or hardware platform in the case of a user environment. Such constraints also include performance requirements, security/safety requirements, operating requirements and availability requirements. The architect needs to develop strategies to address these constraints along with balancing function and service within the available resources and capabilities.

Quality Attributes Important To Users

A more in-depth discussion of quality attributes can be seen in Karl Wiegers book, Software Requirements (Wieger 1999). Some examples of quality requirements that capture how users expect systems to behave can be described as follows: Availability refers to the percentage of the planned up time during which the system is fully operational. It is very important to define the up time, as some

tasks are more time critical and if the system is down during that time it can frustrate users. Reliability refers to the probability of the system executing without failure for a specific period of time. An architect needs to establish quantitative reliability requirements based on how severe the impact would be if a failure occurred and whether the cost of maximizing reliability would negatively impact performance. An architect needs to specify replication and failover scenarios as well as security plans to protect the system from hackers. Usability refers to ease of use and user-friendliness of the product or application. An architect needs to make sure that the users are able to access the system using all desired channels of communication. For instance, the architect may have to document that the users desire to access the application over the web using three types of browsers. Efficiency refers to how well the system utilizes processor capacity, disk space and memory. An architect needs to assure that the systems make efficient use of given resources as, for instance, 100% resource usage can severely affect the performance of the system. Flexibility refers to how much effort is needed to add new capabilities to a system. Flexibility is very important when the system is being developed in an incremental, iterative fashion through a series of successive releases. If the architect anticipates system enhancements, then he or she can choose design approaches that maximize the softwares flexibility. Security refers to precluding unauthorized access to a system, ensuring that the software is protected from virus infection, and protecting the privacy of data entered into the system. There is no tolerance for error concerning the security of the system. Interoperability refers to how easily the system can exchange data or services with other systems. The architect needs to know which other applications the users will employ in conjunction with the product and what data they expect to exchange. Robustness refers to the extent a system continues to function correctly when confronted with invalid input data, defects in connected software, defects in hardware components, or unexpected operating conditions. In conjunction with the users, the architect needs to identify all expected error conditions in order to determine the robustness goals of the system.

Quality Attributes Important To Developers

While the above list indicates quality attributes important to users, the following suggests important concerns for developers: Maintainability indicates the ease of correcting a defect or change in a system. It is critical that systems are developed to accommodate incremental and periodic revision. This is a very important requirement because if developers,

administrators, and operators cannot figure out how to manage their applications, they will not survive past the first release. For example, with regard to my work with Datum, maintaining the application became a nightmare as adding a small feature took a lot more time and sometimes required significant rework. Portability refers to the effort required to migrate a piece of software from one operating environment to another. The architect needs to build a plan to migrate the system to the latest version of the software. My MIS application was not easily portable as every new release of the framework had integration issues that were very time consuming to resolve. Reusability refers to the extent a software component can be used in applications other than the one for which it was initially developed. Developing reusable components costs more compared to developing an application-specific component. An architect needs to specify which components of the system will be reusable and needs to create a library of the reusable components that can be easily integrated with other applications. The MIS application at Datum was designed as a reusable application, which increased its cost of development tremendously. Testability refers to the ease with which the software components or integrated products can be tested to find defects. Testability is very important if the product is being developed incrementally. Frequent testing at each development increment can help determine whether changes damaged any existing functionality. The MIS system I worked on went through many enhancements, and it was very hard to test, understand and maintain, as its cyclomatic complexity was very high. Cyclomatic complexity is a measure of the number of logic branches in a source code module. The more logic branches a system has, the more test scenarios must be developed in order to test these branches.

Relationship between Quality Attributes

An architects role is to achieve the right balance of quality characteristics in the system and make sure to document the quality attribute expectations in the SRS (Software Requirement Specification) in order to deliver a product that satisfies all the systems stakeholders.

Availability Efficiency Flexibility Integrity Interoperability Maintainability Portability Reliability Reusability Robustness Testability Usability + + + +

y y lit lit bi y bi ss ty t a y y ty cy ili y ili ity ity na lit ne er lit ili i i n b il lit st ab r bi ie op nta la ab ib ab u s i bi g r t t c ia x i r s fi e te te a va el eu ob sa A Ef Fl In In M Po R R R Te U + +

+ + + + + + -

+ +

+ +

+ +

+ +

+ + + + + +

+ +

+ + +

+ + +

Figure 1Relationships between quality attributes (Wiegers 1999)

Figure 1 shows the positive and negative relationships between various quality attributes. A plus sign in a cell indicates that increasing the attribute in the corresponding row has a positive effect on the attribute in the column. For example, design approaches that increase a software components reusability can also make the software more flexible, easier to connect to other software components, easier to maintain, more portable, and easier to test. A minus sign in a cell means that increasing the attribute in that row adversely affects the attribute in the corresponding column. Efficiency has a negative impact on many other attributes. For example, the tightest and fastest code written using a specific compiler and operating system is hard to maintain and enhance as well as resistant to porting to another environments. More examples of these can be found in Karl Wiegers book on software requirements, which is also an excellent resource in general for the aspiring software architect.

Lessons Learned
At the end of the project with Datum, I realized I had made tremendous growth as a software architect. I realized that architecting is about finding the best possible solution that addresses the functional requirements of an application or product within many constraints. Therefore it is very important for me to be involved during the requirement phase as these constraints are generally not captured by business analysts or project managers. There are many constraints within which we architects need to work: development timeframe and cost, computing resource availability, external systems we need to interact with, component reuse choices, capacity plans, and so on. And these constraints should be captured during the requirement phase in order to satisfy the needs of all stakeholders depending upon the application or product we build.

Critical Thinking Questions

The following is a list of questions an architect should ask when evaluating nonfunctional requirements, as proposed in a UMBC undergraduate course in Software Design and Development (Mitchell 2004): User Interface and Human Factors o What type of user will be using the system? o Will more than one type of user be using the system? If yes, what kind of rights will each user type have? o What kind of validation should be done by the system? o What types of interfaces will the system have? Hardware Consideration o What hardware will the proposed system be deployed on? o What will be the characteristics of the target hardware, including memory size and auxiliary storage space? Performance Characteristics o Will there be any speed, throughput, or response time constraints on the system? o Will there be size or capacity constraints on the data to be processed by the system? Error Handling o What type of error handling will be provided by the system? o Will input be coming from systems outside the proposed system? System Interfacing o Will output be going to systems outside the proposed system? o Will there be restrictions on the format or medium that must be used for input or output? Quality Issues o What will be the requirements for reliability? o Should the system trap faults? o Will there be a maximum acceptable time for restarting the system after a failure? o What is the acceptable system downtime per 24-hour period? o Is it important that the system be portable (able to move to different hardware or operating system environments)? System Modification

o What parts of the system are likely candidates for later modification? o What sorts of modifications are expected? Physical Environment o What is the physical environment and will it be deployed in one or several locations? Security o Should there be control on the system or any data? o Is physical security an issue? Resources and Management Issues o How often will the system be backed up? o Who will be responsible for the back up? o Who is responsible for system installation? o Who will be responsible for system maintenance?

Sources
[Botzum, et al. 2006] Botzum K, Brown K, Hambrick G. 2007 January 24. Why do nonfunctional requirements matter? IBM DeveloperWorks [Internet]. [cited 2007 January 10.] <http://www128.ibm.com/developerworks/websphere/techjournal/0601_col_bobrha/0601_col _bobrha.html> [Malan 2007] Malan R. [date unknown] Requirements and innovation. The Architecture Discipline [Internet]. [cited 2007 January 10.] <http://www.bredemeyer.com/ArchitectingProcess/VAPColumns/RequirementsA ndInnovation.htm> [Malan, Bredemeyer 2001] Malan R, Bredemeyer D. 2001. Defining non-functional requirements [PDF]. Bredemeyer Consulting [Internet]. [cited 2007 January 10.] <http://www.bredemeyer.com/pdf_files/NonFunctReq.PDF> [Malan, Bredemeyer 2002] Malan R, Bredemeyer D. 2002 February. Architectural requirements in the visual architecting process. The Architecture Discipline [Internet]. [cited 2007 January 10.] <http://www.bredemeyer.com/ArchitectingProcess/ArchitecturalRequirements.ht m> [Malan, Bredemeyer 2003] Malan R, Bredemeyer D. 2003. Architecture strategy. Software Architects: Knowledge, Activities and Characteristics [Internet]. [cited 2007 January 10.] <http://www.bredemeyer.com/ArchitectingProcess/ArchitectureStrategy.htm> [Mitchell 2004]. Mitchell S. 2004 April 28. Nonfunctional requirements. University of Maryland, Baltimore County (UMBC) College of Engineering [Internet]. [cited 2007 January 10.]

<http://www.csee.umbc.edu/courses/undergraduate/345/spring04/mitchell/nfr.htm l> [Wiegers 1999] Karl E. Wiegers. 1999. Software requirements. First edition. Redmond: Microsoft Press.

About the Author

Ranju Saroch works as Technical Architect with ICF International at Fairfax, Virginia. She has more than twelve years of experience in technical architecture design and development for web applications and in applying usability engineering. She has designed web-based applications using object-oriented analysis and design methodologies such as UML.

Glossary
Functional Requirements (FR). They are specific functions, tasks, features or behaviors the system must support. Non-Functional Requirements (NFR). They are reliability, usability, maintainability, cost, development time. Cyclomatic complexity. It is a measure of the number of logic branches in a source code module.