Requirements Classification and Organization

• Week 5 discusses requirements classification, organisation, prioritization, negotiation, and stakeholder goals.

Requirements Classification and Organization

• Objective is defined as understanding how requirements are organized in a software requirements document.
• Unstructured requirements are organized into multiple levels of related groups or clusters.
• Functional and Non-Functional Requirements need to be linked and defined thoroughly.
• Diagram models are a visually appealing way of viewing all requirements to categorize.
• One way to classify is by subject or system area.
• System Architecture Model helps to identify sub-systems and associated requirements.
• Can also classify by source of data.
• It can also be by the type of requirements such as functional/non-functional.

Functional Requirements Classification

• An important step is organizing the requirements into logical clusters to understand and manage the large number of requirements.
• Requirements can be classified by categories that appear convenient.
• This includes the features, use cases, mode of operation, user class, responsible subsystem
• This makes understanding the product's intended capabilities easier.
• Effective to manage and prioritize large groups rather than single requirements.

Requirements Classification - Features

• Features are logically related (functional) requirements.
• This provides a capability to the user that satisfies a business objective.
• Description of a feature includes the name, its description and its priority
• Description also includes stimulus/response sequences and a list of associated functional requirements.
• Features include the name, description and priority, stimulus/response sequences, and a list of associated functional requirements.
• Order Meals is one example of a feature.
• As a feature, Order Meals involves the user to order meals.
• A cafeteria Patron who is verified can order meals to be delivered to a company location, or picked up in the cafeteria.
• A Patron can change a meal order until it has been prepared.
• Priority is High.
• The Stimulus example is, Patron requests to place an order for one or more meals.
• Response example is, System queries Patron for meal details, payment, and delivery instructions.
• Functional Requirements example is, to let a Patron, logged into the Cafeteria System, place an order for one or more meals.
• Should also confirm that Patron is registered for payroll deduction.

Non-Functional Requirements: FURPS+ Model

• A possible model to categorize the requirements is the FURPS+ Model.
• FURPS+ consists of: Functional, Usability, Reliability, Performance, Supportability.
• Supportability also includes: Implementation, Interface, Operations, Packaging, and Legal aspects.

FURPS+ Checklist

• This checklist is used as an aid when planning requirements elicitation events. Structured walkthroughs are held to verify that the requirements analysis and documentation covered all types of requirements.
• Requirements should cover all the FURPS+ categories.

FURPS+ Categories

• Functionality: Defines what the system must be able to do.
• Functionality includes features, security, and user requirements.
• Usability: Deals with requirements related to the user interface.
• Usability Includes user-friendliness, accessibility, online help, and visual design guidelines.
• Reliability: System's ability to perform specified routine and non-routine conditions for a specified period of time.
• MTBF (Mean Time Between Failures): Mean time between service failures of the same service.
• MTBSI (Mean Time Between System/Service Incidents): Mean time between failures (of any service).
• MTTR (Mean Time To Repair): Mean elapsed time to fix and restore a service from the time an incident occurs.
• Performance: Describes how the system must behave with respect to time and resources.
• Performance includes measures of speed, efficiency, availability, and accuracy.
• Metrics include response time, recovery time, start-up time, throughput, and resource use.
• Supportability: Requirements to monitor and maintain the system.
• Supportability Includes abilities to test, configure, install, and upgrade the system.
• Plus (+): Additional constraints on the system.
• It includes design, implementation, interface, and physical requirements.
• It also covers legal, compliance, regulatory, and copyright requirements and constraints.

Non-Functional Classifications

• Product requirements: Specifications for how the delivered product must behave.
• Organizational requirements: Consequences of organizational policies and procedures.
• It can include process standards, implementation requirements, etc.
• External requirements: Factors external to the system and its development process.
• It can include legislative and interoperability requirements.

Requirements Prioritization and Negotiation

• Prioritization is used to find requirements and resolve conflicts through negotiation.
• The two main stages involve prioritizing and finding and resolving conflicts using negotiation.
• Stakeholders usually meet to resolve differences and compromised

Requirements Prioritization and Negotiation Details

• Importance to the overall system is key when prioritizing requirements.
• An appropriate priority system is needed to classify requirements and specifications during stakeholder negotiations.
• Requirement conflicts need to be resolved through compromise.
• A summary of each negotiation meeting should be included within the requirements documentation.

Requirements Prioritization Notes

• Prioritization is needed select what to implement.
• Customers usually ask beyond reason and it's necessary balance time-to-market with functionality.
• To decide which features go into the release, for each requirement/feature, analyze
• Prioritization asks about how important is product to customer, costs, and risks involved.
• Prioritization has requirements to include or exclude.
• Some requirements must be included, and some should definitely be excluded.
• "Nice-to-haves", are the left over features that must be selected from.

Prioritization Techniques

• Analytical Hierarchy Process (AHP): N X (n-1)/2 at each hierarchy level.
• Cumulative Voting: the 1-Dollar test.
• Given 100 imaginary units ($, hrs, etc.) for distributing between requirements.
• Numerical Assignments: Assign requirements into groupings like critical, standard, and optional.
• Ranking can assign the most important requirements from 1 to n.
• An example of a prioritization technique is top-ten requirements.

Cost-Value Approach in Prioritization

• Calculate return on investment for what to implement.
• Measure the importance of the requirement for the project.
• Measure the relative cost of implementing an individual requirement.
• Balance Cost Value Tradeoff

Estimating Cost & Value

• Two approaches: Absolute Scale and Relative Values
• Absolute Scale provides dollar values, but requires much domain experience.
• Relative Values relies on ratings, but much easier to elicit
• This turns the entire process into a sorting problem.

Some Complications

• Quantifying is hard, as it's easier to compare, but hard to truly determine value amounts
• Requirements comparability is unlikely.
• e.g. are at different level of abstraction, different functionality for the customer, etc.
• Requirements are not independent and can depend on each other
• Stakeholders often are not consistent.
• Stakeholders also may not agree on direction assessments.

Hierarchical Prioritization

• Requirements can be grouped into a hierarchy such a goal tree or a NFR tree.
• Only comparisons between branches of a single node.

Analytical Hierarchy Process (AHP)

• AHP's equation: n x n matrix (for n requirements).
• Estimate the eigenvalues for each requirement using "averaging over normalized columns"

Plot ROI Graph

• Complete AHP process twice by estimating cost and estimated value.
• Use results to calculate ROI ratio:

Selection Criteria Notes

Return of Investment Ratio is not the only way to prioritize

Requirements Negotiation

• Interacting with stakeholders can be difficult due to vague or implicit knowledge
• Stakeholders may also have unrealistic demands or expectations.
• Inconsistent stakeholder input can also lead to ambiguity.
• This could lead to conflicting or redundant requirements.
• Political and Economic factors also influence.
• Business stakeholders, the economy, being bought out, and company restructuring do impact.

Requirement and Stakeholder Conflicts

• Stakeholders may request conflicting requirements and may not realize they are requesting conflicting requirements.
• Functional v non-functional Requirements are bound conflict.
• A stakeholder will be adamant about their requests, and try to suppress conflicting ones.
• Regular negotiations are held to come to a compromise.
• Stakeholders that are voted down may harm the process out of spite..
• Documentation of these incidents needs to be in a secure place for archiving purposes.

Conflicting Requirements

• Requirements are in conflict if you cannot reasonably implement them side by side.
• HR requesting age, but Data Privacy not wanting age to be captured can be in conflict.

Severity of Conflicts

• Severity of conflict occurs through mutually exclusive or interfering ideas.

Causes of Conflict

• Can be caused by competition of resources, differing preference and nuisances.
• Could come down to disagreeing on values, beliefs, differing opinions,
• Some examples are communication, structural, and personal conflicts.

Interesting Results about Conflicts

.

• Deviant behaviour and conflict in small group decision making is commonly found
• Increased aggression is more present when people are not able to communicate effectively

Basic Approaches in Conflict Resolutions

• Negotiation: Participants collaboratively explore to find the best settlement for both parties.
• This can be done through integrative behaviour and constructive negotiation.
• This is opposed to distributive/competitive negotiation.
• Competition is about maximizing gain regardless of impact on others.

Conflict Resolutions - Third Party

.

• Appeal to outside source: occurs with rule-book, authority figure, toss of a coin, etc.
• In third-party resolution, breakdown of either negotiation or competition as resolution methods.
• Judicial is a type, as cases are presented by each participant are taken into consideration.
• Extra-judicial is a resolution by factors other than cases presented.
• Arbitrary is a resolution such as tossing a coin.

Conflict Resolution - Bidding and Bargaining

.

• Bidding requires stating all desired terms.
• Bargaining requires searching for a satisfactory integration of bids.

Goals Analysis and Modeling

• The goal is the stakeholder objective for the system.
• Takes into consideration all aspects of the software, and it's environment.
• Stakeholders have interest and involvement in the system
• Customers, end users, system developers, system maintainers are stakeholders
• Goal model consists of a goal hierarchy and relates high-level goals and low-level system requirements.
• Goals derive from interactions with the stakeholders. Also, is disclosed in requirements, and analyzing similar / current systems.

Stakholder Goals

.

• Advantage of identifying this method requires high level intuitive reasoning.
• Explicit reasons for conflict is established.
• Disadvantage captures a static picture - what if goals change over time?
• Also can regress forever up (or down) the goal hierarchy

Example of goals

• Goal examples: Credit card information is kept private & is accurate, safe transportation.
• Non-example: System will be implemented in C++.

Goal Exercise

• An exercise to order list of goals from high to low of concern.
• An example is from timetable from a system

Types of Goals

• Functional (Hard) describes the system functionality
• Functional provides system functions and well defined criteria.
• Non-Functional include quality of life requirements (Soft/ Fuzzy).
• For a system, to describe desired system qualities
• This consists quality, reliability, accuracy, performance, security.
• This can be hard to define and satisfy fully.

Goal (Requirements) Categories

• It is broken up into what provides satisfaction, information or a stimulus/response.

Why Goal Models?

• Used for when requiring early elicitations for system.
• Good for understanding the "Why" and identify problems.
• Explores system solutions and done before Uml Modeling
• Goal models provide rationale for each set of given requirements.
• Also identifies stable information and guides requirement elaboration.

Stakeholders' Goals

• Focus on why a system is required to express the why is expressed as a set of stakeholder goals.
• Provides a way to refine the goals to reach specific requirements for the system.
• Involves to document, organize, and classify goals for evolution with elaboration and refinements/ alternatives.

Goal Analysis - Softgoals and Refining

• It's important to model softgoals using refinements for contributing factors

Goal Refinement

• Expresses how an abstract goal can be established by more low-level goals.
• Two types of Goal Refinement: AND and OR refinement.

Conflicts Conclusion

• Basic Approaches in Conflict Resolutions involves in collaborative exploration.
• This is resolved by Participants by attempting to find the best compromise that satisfies most parties.
• Bidding is commonly practice and is resolved in Bidding process.

Summary

• Topics discuss cover Requirements Classification and Prioritization, which leads to Conflicts and leads to Requirements Negotiation.
• At the final round stakeholders are considered by analyzing and developing goals.