Introduction to NFR
NFR as Constraints
Two Types of Constraint
Internal Quality
External Quality
Identifying the Non Functional Requirements
NFR Analysis approach
How to Define a Quality
Step 1
Step 2
Methods to create a BASELINE
Methods to create Targets or constraints
Common Methods for establishing Targets and Constraints include
Estimating NFRs in Scrum
Cost of Initial compliance
Cost of Ongoing compliance
Estimation
Estimating NFR as a User Story
NFR can be included as a part of FR story card
Explanation
Workflow
Summary
Introduction to NFR
- NFR is qualified to specify “how well” the “what must behave”
“Say you are building a 2BHK house for your customer with a hall and a beautiful lawn, The user need hall and double bed room, not care how structured ,sized and strong. To provide a valuable user experience, we should provide structured and the strongest build with the perfect maintainability”
“Another example is the training part of our website. If its performance is poor, and if it takes too long to receive a confirmation once a participant has been registered, users are unlikely to have an enjoyable experience. Other common nonfunctional requirements include robustness, interoperability, usability, and compliance with a regulation or a standard”
- It can be called as constraints on the system,NFR imposes constraints on the system, if we want security/reliability on our project
- All Functional requirements to meet with non functional requirements
- “Say House with 3 bedrooms having one bedroom size is completely different “
NFR as Constraints
- A constraint is a condition to make the requirements in line with quality expectations
- It helps determine whether you have satisfied the non-functional requirements
- NFR is always a constraint for other user stories
- Any backlog item may be constrained by NFR
- Constraint to be obeyed either during the implementation by the builders (internal quality) or at run time by the software (external quality).
- Constraint has two parts :a narrative and a list of acceptance criteria
- Narrative describes the non functional requirement, where as the criteria clarify the interaction and describe the environment
- BOTH are required to validate the constraint
Two Types of Constraint
Internal Quality
- Rule is a “constraint” that sets a limit to comply during software construction
- Impose constraints using “Rules”
- Internal qualities such as maintainability and testability, which is barely visible by the stakeholders but simplify how to build the software
- Each user story is not « Done » until each rule is confirmed
- It can be confirmed by doing peer reviews /inspection
Non-Functional Requirement |
Rule |
Simplicity |
Naming convention: Practices that ensure code is its own best documentation by allowing useful information, such as programming constructs, to be deduced from the names. |
Non-Functional Requirement |
Definition |
|
Simplicity |
Ease to understand or explain |
|
Maintainability |
Ease to change and evolve with minimal effort |
|
Testability |
Ease to confirm conformance by observing a reproducible behavior |
|
Portability |
Ease to reuse for multiple platforms |
|
Extensibility |
Ease to takes into consideration future growth |
|
External Quality
- Restriction is a “constraint” that sets a limit to comply during software execution
- External qualities such as performance, correctness, security and usability, which carry out the software’s functions at run time, and as such, are not only visible by stakeholders but also highly desirable
Ex: User requires 2 BHK but it requires the rooms in good shapes as well
- It can be confirmed by test(s) ,automation or performance testing
- Restriction is specific for one scenario
- Restriction has a measurable quality objective
- Restriction is confirmed by test(s)
Non-Functional Requirement |
Definition |
Correctness |
Ability with which the software respects the specification. |
Performance |
Ease with which the software is doing the work it is supposed to do. Usually it is measured as a response time or a throughput. |
Reliability |
Ability with which the software performs its required functions under stated conditions for a specified period of time. |
Robustness |
Ability with which the software copes with errors during execution. |
Scalability |
Ability with which the software handles growing amounts of work in a graceful manner. |
Security |
Degree to which the software protects against threats. |
Usability |
Ease with which the software can be used by specified users to achieve specified goals. |
Restriction (External Quality Constraint)
- Restriction is specific for one scenario
- Restriction has a measurable quality objective
- Restriction is confirmed by test(s)
- Restrictions should be SMART
Characteristic |
Description |
Specific |
It should target a piece of functionality that is small, consistent and simple |
Measurable |
It imposes a limit that is measurable, otherwise how would you know when you’ve addressed it |
Attainable |
It is recognized as achievable by the team |
Relevant |
It is directly related, connected, and pertinent to the non-functional requirement |
Traceable |
It is linked with a requirement and a target that justifies why it exists |
How do you conform External Restriction with Tests?
- Correctness: Acceptance testing
- Performance: Response time or throughput testing
- Reliability: Testing over a period of time (memory leaks???)
- Scalability: Load testing (with growing amounts of work)
- Security: Intrusion testing
- Usability: Testing with real users
Identifying the Non Functional Requirements?
Non functional requirement analysis is the most important activity in the requirement engineering. In the requirements engineering we need to elicit both functional and non functional requirements. Though we satisfy the functional requirements if we cannot satisfy the non functional requirements people may not accept the product.
Here we see some methods and approaches to elicit and analyze the non functional requirements in product
NFR Analysis approach
Non functional requirements elicitation and analysis involves a variety of people in an organization. In order to elicit and analyze requirements completely multiple views needs to be considered to meet all stakeholder expectations Here we will talk about one of the method for elicitation and analysis of NFR is called Four Layered Approach. This approach is used to identify all non functional requirements from multiple views of different stakeholders.
Non Functional requirements analysis process
The non functional requirements identification process can be divided into four steps as follows
Step 1: Identify the key stake holders of the system [or] <Who> are the stakeholders?
Step 2: Generate the goals from stakeholders based on developer’s knowledge and experience [or] <What> are the services<goals>?
Step 3: Decompose goal into sub goals [or] <What> are the sub goals of each service?
Step 4: identify non functional requirement for each sub goal [or] How the goals are achieved under constraints?
As a brief the team has to identify the stake holders then by discussing the goals of the system, the non functional requirements for the system should come up. You can see the following explanation to get the detailed explanation of four layered analysis for non functional requirements
Four layered analysis of Non functional requirements identification
As you see the above picture, the NFR analysis has been done on the product video management system which is specifically for recording the cameras motions through recorder and playing back it. Also it provides facility for rendering live videos on screens.
Usually the NFR requirements identification and analysis should start with identifying the stake holders of the product by arranging a meeting, in which the goals of the system should be identified and discussed it. Here I have taken ‘Video Management System’ product as an example for explaining this analysis process.The Stake Holders shall be a product owner, system administrator, user, Architect of the system, and Quality manager. So with the stake holders the team will identify the goals, sub goals of the system with the non functional requirements,
AS you see in the above picture searching the video clip could be a one goal for the system, in which sub goals here are Search the clip by name, Search the clip by length. These sub goals non functional requirements will be identified during the meeting.
For Ex: Clip result should come in 5 seconds
As like that, the goals with the sub goals of the system will be identified with the non functional requirements. Using this approach the complete set of non functional requirements will be identified.How to find the CRITICAL Non Functional requirements?The following traceability matrix is used for finding critical non functional requirements
NFR Type |
Goal 1
Login |
Goal 2
Searching
Video Clip |
Goal 2 Exporting Video Clip |
Goal 3
Add
Camera |
Goal 3
Searching Cameras |
Goal 4
Assign Camera |
Goal 5
Configure
Camera |
Performance |
2 |
2 |
|
1 |
2 |
1 |
|
Usability |
|
|
1 |
|
|
|
1 |
Reliability |
|
|
|
1 |
|
2 |
|
Based on the analysis using four layered, we shall conclude which NFR is a critical one. If you see the above table, we can easily conclude that performance NFR’s are the most critical NFR, because all the goals requires this.The critical NFR’s which are identified must be implemented in the system.Quantifying the Non Functional RequirementsOnce we have identified the non functional requirements, we need to quantify it to ensure stakeholder’s desires are clearly understood by everyone
How to Define a Quality
There 2 steps to define the quality
STEP 1:
NAME: In then form of quality.subquality
SCALE: What to measure (units)
METER: How to measure (method)
Real Time Example – STEP 1
NAME: Usability. Efficiency
SCALE: Number of Actions to complete a Transaction from a Location
METER: Average observed results from testingsite.com usability tests
Actions: One of {Data entry, Click, Scroll}
Transactions: One of {eCommerce [Shop, Purchase], Self Service [Activate, Change Plan]}
Location: One of {Home Page, My Account}
As a first step we should identify the name, appropriate scale of measure and method of measuring as like in the above format
STEP2:
TARGET: Success level to achieve
CONSTRAINT: Failure Level to avoid
BASELINE: Current Level
Methods to create a BASELINE
Method of creating Baseline |
Method |
Description |
Use Existing Meter |
Use Existing method of measuring such as Report. Ex: Usability tests to measure, Using tools to measure |
Create a New Meter |
Create a new method of measuring whichever is easy to measure |
Methods to create Targets or constraints
Common Methods for establishing Targets and Constraints include
|
Method |
Description |
Improvement from Baseline |
Plan a 20%-40% improvement over current levels by next year |
Comparison with other competitors |
Benchmarking yourself against leading competitors and setting levels based on their capabilities |
Using the above format/methodology we shall define a quality with the baselines and targets
Estimating NFRs in Scrum
Challenges with estimating NFRs involves two costs
- Initial compliance
- Ongoing compliance
Cost of Initial compliance
- The amount of time the team spends on initial NFR development and the performance testingInitially zero code, over the period of sprints the code base is ready for the NFR development
Cost of Ongoing compliance
- Consider the NFR development and testing has done on Sprint 5, In sprint 6 the team is adding some more features relating to that. Here is where the second cost – Ongoing compliance comes
- The moment NFR has accepted by the team, they need to remain in compliance with the NFR for the remainder of the project
In Other words “If the NFR has been developed and tested by the team in sprint 5 [For Ex], Also if new features related to the NFR has added into the sprint 6, the Team should conform the NFR till the end of project”
Estimation
- Estimate the cost of initial compliance and ongoing compliance separately
- Estimate the initial compliance as like any other user story or product backlog
- The Team and PO will need to incorporate an estimate when they will do this? Every sprint or every n sprints
- Team can then estimate how much work will be involved over the planned number of sprints and allocate that amount of work to each
“Suppose the team and product owner agree that they will do performance testing in every fourth two-week sprint. The team then estimates that it will take six points of work every fourth sprint. That’s about 1.5 points per sprint”
Estimating NFR as a User Story
Can you imagine and tell why separate userstories will be created in theproduct backlog for the NFR, why not user story itself having NFR parameters?Assume your large product like Building security system have multiple major modules like Access Control, Video.etc.. In a particular release/version there might be a functional requirements alone from video module,and a few non functional requirements from the Access control.In this case the highest priority would be for the functional requirements in the sprints. And a very less value for the non functional parameters
Example:
Refer the below mentioned diagram
NFR Userstory
“As a user , I want the access credentials should download in 10 seconds to the controllers”Assume this nfr takes 6 story points to complete it. Since the NFR is less priority one and also we need this to be parallely developed one, so we are planning to take 2 story points of NFR in each sprint.
So the above is going to split in sprints as like below
Sprint 1 – Internal quality rules should be applied throughout the code portions of above NFR
Sprint 2 – Towards external quality acheviement ,performance tuning should be done in the communication layer
Sprint 3 – Towards external quality acheviement, performance tuning should be done in the user layer
Sprint 5 – As a whole of above, the performance testing will be done
NFR can be included as a part of FR story card
This time NFR parameters come up along with the functional requirements story cards. The background of this type of estimation is along with the functional story development, NFR parameters also should also be considered.Consider an example that we got a functional requirement user story called “Searching and retrieving of video clips from network video recorder”In which the NFR parameters will also be included as a part of user story
Example: Retrieval of video clips in 10 seconds
Scalability View: As a user I need a scalable clip search module in video to search and list the clips when the system is configured in more than 20000
Determines if the application is stable under varying load
Reliability View: As a user I need a clip search or clip download operation in 10 seconds when the system is running for more than 10 days
Determines if the application is reliable for a period of time
Performance View: As a user I need a clip search or clip download operation responds in 10 seconds when the system is configured in more than 20000 cameras
Determines whether the application responds quickly
Explanation:
Let’s talk about the above NFR representation, During the grooming meeting the user stories will be identified with the NFR parameters, As you see in the above picture, scalable/reliable/performance parameters also be identified at the beginning.Once the sprint starts the development of functional stories with the NFR parameters are started developing and completed with the functionally tested including NFR at the end of sprint.During the sprint or in the beginning of the sprint, if any constraints have identified [i.e. if any NFR implementation affects one or more user stories]It should be added into the product backlog.Once a new constraint is added to the system, any stories in the product backlog that will have to comply with this constraint may need re-sizing if there is material time required to comply with the constraint. Said another way, all estimates for future stories will need to take into account the fact that the constraint must be complied with in order to call the story “done.”
Constraint Example:
Recorded clips of various cameras need to search and make sure it lists within 10 seconds.
Summary
- Explore nonfunctional requirements that apply to the entire product or to important features early on – It makes you create a greater user experieance and make the right architecture and technology decisions
- Capture the requirements precisely to ensure testability