Written (Programming) Assignment Unit 2

Computer Science, University of the People

Software Engineering 1

CS 2401

Instructor: Martins Joseph

27th November, 2024

 Analysis and Acceptance Testing of Nonfunctional Requirements

As highlighted by Continuous Delivery (2020), nonfunctional requirements (NFRs) play a

crucial role in defining the quality attributes of a software system. They complement functional

requirements by addressing how the system performs tasks rather than what tasks it performs.

Below is an in-depth analysis of the provided NFRs, categorizing them as testable or non-

testable, and providing acceptance tests where applicable.

Requirement A: "The user interface must be user-friendly and easy to use."

Analysis

This requirement is ambiguous and lacks specific, measurable criteria, making it challenging to

verify directly. As argued by Marsic (2012), vague terms like "user-friendly" introduce

subjectivity and impede the development of clear acceptance tests. While usability testing can

provide insights, the interpretation of "user-friendly" varies among users.

Recommendation and Acceptance Test

To make this requirement testable, specific usability metrics must be defined, such as:

1. Task Completion Rate: Percentage of users completing tasks successfully.

2. Error Rate: Average number of errors made by users.

3. Satisfaction Score: User feedback collected through surveys.

Test Plan: Conduct usability testing with a sample of target users. Define tasks to perform (e.g.,

navigating through features) and measure the success rate, errors, and satisfaction scores using

standardized tools like SUS (System Usability Scale).

Requirement B: "The number of mouse clicks the user needs to perform when navigating

to any window of the system’s user interface must be less than 10."

Analysis

This requirement is concrete, measurable, and easily verifiable, making it highly testable. As

stated by Bochmann (2010), defining clear thresholds for metrics enhances the testability of

requirements.

Acceptance Test

1. Identify all windows in the system's user interface.

2. Develop a test script to simulate navigation paths to each window.

3. Count the number of mouse clicks required for navigation.

Test Criteria: Pass the requirement if all paths require fewer than 10 clicks. For automation,

tools like Selenium can be used to simulate and validate navigation flows.

Requirement C: "The user interface of the new system must be simple enough so that any

user can use it with a minimum training."

Analysis
Like Requirement A, this is subjective and non-testable in its current form due to the vagueness

of "simple" and "minimum training." According to TutorialsPoint (n.d.), nonfunctional

requirements should specify quantifiable and objective measures to be testable.

Recommendation and Acceptance Test

Quantify "minimum training" by defining a standard training duration (e.g., 15 minutes) and a

set of basic tasks users must perform post-training.

Test Plan:

1. Provide a standardized training session.

2. Assign tasks such as creating a profile or generating a report.

3. Measure task completion rates and time taken by users.

Test Criteria: Success is defined as at least 90% of users completing all tasks within the

allocated time after training.

Requirement D: "The maximum latency from the moment the user clicks a hyperlink in a

web page until the rendering of the new web page starts is 1 second over a broadband

connection."

Analysis

This requirement is specific and quantifiable, making it highly testable. As stated by Wiegers

(n.d.), measurable performance attributes are key to verifying NFRs effectively.

Acceptance Test

1. Use performance testing tools like Apache JMeter or Lighthouse to measure page latency.

2. Define a broadband connection speed (e.g., 50 Mbps).

3. Simulate user interactions by clicking hyperlinks and recording the latency until page

rendering starts.

Test Criteria: The requirement passes if latency remains under 1 second for all tested hyperlinks

under defined network conditions.

Requirement E: "In case of failure, the system must be easy to recover and must suffer

minimum loss of important data."

Analysis

This requirement is partially testable. The ease of recovery can be verified by conducting disaster

recovery tests, but "minimum loss of important data" requires clarification. As argued by Marsic

(n.d.), requirements must specify thresholds or criteria for measurement.

Recommendation and Acceptance Test

1. Define "Minimum Loss of Data": Specify acceptable data loss limits (e.g., recovery

point objective [RPO] of 5 minutes).

2. Recovery Scenarios: Simulate failures such as database crashes or power outages.

3. Measure Recovery Time and Data Integrity: Record the time taken to restore the

system and validate the completeness of recovered data.

Test Criteria: The requirement passes if the system recovers within the defined recovery time

(e.g., RTO of 10 minutes) and data loss remains within acceptable limits.

Case Study Examples

1. Netflix’s Approach to Performance Testing

Netflix employs chaos engineering to simulate failures and ensure system resilience

(Garlan & Shaw, 1994). Applying similar practices can validate the ease of recovery and

data loss thresholds.

2. Amazon’s Usability Testing

Amazon routinely measures user satisfaction using metrics like click-through rates and

task completion times. This approach aligns with verifying requirements A and B.

Conclusion

Effective requirements elicitation and validation are critical in software engineering. Testable

NFRs ensure systems meet user expectations and maintain quality standards. By defining clear,

measurable criteria for ambiguous requirements, developers can create robust test plans,

enhancing system reliability and user satisfaction. As argued by Wiegers (n.d.), bridging the gap

between user expectations and technical feasibility begins with well-articulated requirements.
 References

1. Bochmann, G. (2010). Introduction to requirements analysis and specification. The

University of Ottawa. Retrieved from

http://www.site.uottawa.ca/~bochmann/SEG3101/Notes/SEG3101-ch3-1%20-%20Intro

%20to%20Analysis%20and%20Specification.pdf

2. Continuous Delivery. (2020, August 19). How to write acceptance tests [Video].

YouTube. https://youtu.be/JDD5EEJgpHU?si=PekRS-cIgfHV_zZQ

3. Garlan, D., & Shaw, M. (1994, January). An introduction to software architecture.

Carnegie Mellon University. Retrieved from

https://www.cs.cmu.edu/afs/cs/project/vit/ftp/pdf/intro_softarch.pdf

4. Marsic, I. (2012, September 10). Software engineering. Rutgers: The State University

of New Jersey. Retrieved from

https://my.uopeople.edu/pluginfile.php/57436/mod_book/chapter/46513/

CS4403MarsicTextbook.pdf

5. Marsic, I. (n.d.). Software engineering lecture 5: Requirement engineering

[PowerPoint slides]. Rutgers: The State University of New Jersey. Retrieved from

https://my.uopeople.edu/pluginfile.php/1927486/mod_book/chapter/539654/lec-

5%20RequirementsEng.ppt

6. TutorialsPoint. (n.d.). Software requirements. Retrieved from

http://www.tutorialspoint.com/software_engineering/software_requirements.htm

7. Wiegers, K. (n.d.). When telepathy won’t do: requirements engineering key practices.

Process Impact. Retrieved from http://www.processimpact.com/articles/telepathy.html