BR Chapter 11: Non-functional requirements

Functional versus Non- functional requirements:

Non-functional requirements do not alter the product’s essential functionality. That is, the functional requirements remain the same no matter which properties you attach to them. At the risk of confusing matters, the non-functional requirements might add functionality to the product. In the security example, the product would have to do things to make certain that only supervising engineers alter the data, but that functionality is needed for a non-functional reason—in this case, security. Perhaps it is easier to think of the functional requirements as those that cause the product to do the work and the non-functional requirements as those that give character to the work, and even easier to say that functional requirements are verbs and non-functional requirements are adjectives.

Non-functional requirements make up a significant part of the specification. Provided the product meets the required amount of functionality, the non-functional properties—how usable, convenient, and inviting it is (see, for example, Apple’s iPad in Figure 11.1)—may be the difference between an accepted, well-liked product and an unused one. Keep in mind that a large part of what people see or feel with your product is there because of the nonfunctional requirements.
Use cases and Non-functional requirements:



The non-functional requirements, however, do not fit so neatly into this partitioning theme. Some of them can be linked directly to a functional requirement, some apply to the product use case as a whole, and some apply to the entire product.
Some Non-functional requirement types:



                           I.          Look and feel requirements: This requirement does not say the company logo must occupy 10 percent of the screen, nor does it talk about the colors or the typefaces to be used. It simply states that the product must comply with the branding standards your organization has established. These standards are published elsewhere—your own organization has a department (usually the communications department) or group responsible for these standards—and the designer has access to them. The fit criterion, when you add it, measures compliance with the standards.

Developers of products intended for the Web should place a great deal of emphasis on the look and feel requirements. Your client has in mind the kind of experience he wants visitors to the site to have.



                         II.          Usability and humanity requirements: This requirement captures the intention of your client, and for the moment, it is sufficient; later you will complete it and make it testable. “Easy to use” and “easy to learn” are slightly different characteristics. Easy-to-use products are designed to facilitate an ongoing efficiency, so perhaps some training is necessary before using the product. For example, suppose you were specifying a product to be used for some repetitive task in an office by clerical workers. You would be well advised to make it easy to use, even if the ease of use means training people to use the product, because the ongoing efficiency will pay for this extra effort many times over. Adobe Photoshop is a case in point. Photoshop is a complex product that offers an amazing wealth of options for the manipulation of digital images to its intended audience of graphic artists and photographers. The Photoshop learning curve is a steep one: There is lot to be learned, and we would venture to say that it is not particularly easy to learn (at least it was not for one of your authors). However, once learned, Photoshop’s features make manipulating images a straightforward—even easy—task. Given the depth of functionality needed to do the task and its inherent complexity, Adobe has made its product easy to use once you have learned how to use it.



                        III.          Performance requirements: When you are thinking about performance requirements, consider such aspects as these:



● Speed to complete a task

● Accuracy of the results

● Safety to the operator

 ● Volumes of data to be held by the product

● Ranges of allowable values

● Throughput, such as the rate of transactions

● Efficiency of resource usage

● Reliability, often expressed as the mean time between failures

● Availability—the uptime or time periods when users can access the product

● Fault tolerance and robustness

 ● Scalability of most of the above



                       IV.          Operational and environmental requirements: Operational requirements are also written when the product has to collaborate with partner products, access outside databases, or interact with other systems that supply information. These items show up as actors on the product use case diagram, or as adjacent systems on the work context model.

If you are building products for sale, you should include any requirements needed to turn the product into a distributable or saleable item. It is also appropriate to describe any requirements that relate to the successful installation of the product.



                         V.          Maintainability and support requirements: Usually at requirements time you do not know exactly how much maintenance your product will undergo in its lifetime, nor do you always know which type of maintenance it will need. Nevertheless, maintenance can, to some extent, be foreseen for certain products. Consider whether any expected changes will occur in the following areas:

● Organization

● Environment

● Laws that apply to the product

● Business rules



                       VI.          Security requirements: Security is perhaps the most difficult type of requirement to specify, and potentially the one posing the greatest risk to the owning organization if it is not handled correctly. When you write security requirements, consider the nature of security as it is applied to software and allied products. Shari Lawrence Pfleeger points out that security can be thought of as having three aspects:

● Access: The product’s data and functionality are accessible to authorized users and can be produced in a timely manner. Other access requirements focus on denying access to unauthorized people. 

● Privacy: Data stored by the product is protected from unauthorized or accidental disclosure.

● Integrity: The product’s data is the same as the source, or authority, of the data, and is protected from corruption

Comments

  1. Yogesh JaglanDecember 2, 2019 at 9:18 PM

    Integrity
    Integrity means that the information held by the item relates precisely to what was conveyed to the item from the neighboring framework (the position for the information). You should think about necessities for avoiding the misfortune or debasement of information and, should the most exceedingly awful occur, recouping lost or adulterated information. Your item, when it goes into creation, will hold information that is imperative to the owning association—respectability necessities are expected to ensure that information. In our de-icing model, climate stations send information about temperature what's more, precipitation to the IceBreaker item. The climate station starts the information and, along these lines, is the expert for it. Any duplicates of this information, such
    as those held by IceBreaker, must be dedicated to the climate station's variant.

    ReplyDelete
  2. Patience NgcoboDecember 2, 2019 at 10:48 PM

    Nonfunctional Requirements (NFRs) define system attributes such as security, reliability, performance, maintainability, scalability, and usability. They serve as constraints or restrictions on the design of the system across the different backlogs. Nonfunctional requirements can have a substantial impact on solution development and testing. NFRs are tricky to specify; it’s easy to go overboard. For example, a statement like “99.999 percent availability” may increase development effort exponentially more than “99.98 percent availability.” Sometimes that’s necessary, and other times it’s not. But the impact of the NFR must be well understood by those defining requirements. Similarly, if not given enough thought, physical constraints such as weight, volume, or voltage may cause the solution to be overly complicated and costly.

    ReplyDelete
  3. Dalsher Singh VirkDecember 3, 2019 at 11:12 PM

    Non-functional requirements are not limited to these topics and extend even to cultural requirements. Cultural requirements specify special factors that would make the product
    unacceptable because of customs, religions, languages, taboos, prejudices,
    or almost any other aspect of human behaviour. Cultural requirements are
    needed when you try and sell a product into a different country, particularly
    when its culture and language are different from your own.

    ReplyDelete

Post a Comment

Popular posts from this blog

BR Chapter 12: Fit Criteria and Rationale

A satisfying viewpoint (among a large number) of Kent Beck's eXtreme Programming system is its emphasis on composing experiments before composing the code. The experiment characterizes the measuring stick that the executed code must match. The fit model is pretty much something very similar: It is a measuring stick for the necessity. By adding a fit rule to the necessity, you are, basically, composing its experiment. In the event that you are utilizing client stories, at that point we firmly propose that you give specific consideration to the explanation given for the usefulness. This is pretty much equivalent to the justification, and is a significant supporter of winding up with the right item. Composing experiments on the back of the story card ought to accomplish a similar reason as the fit standard we talk about here.  For each of the non-practical necessities yielded by the blog, we presently propose determining the fitting fit rule, affirming it with the partner, and compo...
Read more

BA Chapter 9: Underlying Competencies

Image
Underlying Competencies are a description of the behaviours, characteristics, knowledge, and personal qualities that support the practice of business analysis. BABOK® defines 6 key groups of competencies that a BA is expected to possess. Each competency group constitutes of multiple sub competencies which are as discussed below: (Source: https://www.modernanalyst.com/Resources/Articles/tabid/115/ID/1287/Developing-a-Competency-Model-for-Business-Analysts.aspx) 1.      Analytical Thinking and Problem Solving : These skills are required for business analysts to analyze problems and opportunities effectively, identify which changes may deliver the most value, and work with stakeholders to understand the impact of those changes. Analytical Thinking and Problem-Solving core competencies include: ·            Creative Thinking ·           Decision Making ·  ...
Read more

BR Chapter 6: Scenarios

Image
At this stage of the requirements process, the business analyst has identified the business events as well as the business use case which we referred to as BUC and these correspond to the business events.   Below are some of the techniques the Business Analyst can use to communicate requirements to the stakeholders: Scenarios The Business Analyst can use Scenarios to model and record the BUCs. A scenario is an outline of a plot, or a postulated sequence of steps - it tells the story of a business use case.   The scenario is a neutral medium, and one that is both simple and understandable to all stakeholders.  A business analyst would use a scenario like this to elicit, and then describe, a business use case to its interested stakeholders. The BUC is a discrete amount of functionality; it happens in its own time frame and can be considered separately from other parts of the work’s functionality. The BA model a scenario and use it to reach a...
Read more