Understanding System Requirements

Requirements

• A requirement is what the system must do or its characteristics.
• Requirements capture the purpose of a system and express the ideas to be embodied in the system.
• A requirement is a statement about a proposed system that all stakeholders agree must be made true for the customer's problem to be adequately solved.
• Requirements must be short, concise and valid and help solve the customers problem
• Requirements are conditions/capabilities needed by a user to solve a problem or achieve an objective.
• Requirements are conditions/capabilities that a system must meet to satisfy contracts, standards or specification.
• System customers specify requirements and check if they meet needs, also specify changes.
• Managers use requirement documents to plan system developments and bids.
• System engineers use requirements to understand what system must be developed.
• System test engineers use requirements to develop validation tests for the system.
• System maintenance engineers use the requirements to understand the system and the relationships between its parts.

Requirements Engineering (RE)

• Requirements Engineering is analyzing, specification, development, elicitation and management of the requirements of the stakeholder for new and evolving systems.
• RE is identifying the purpose of a software system and the contexts in which it will be used.
• Key activities include inception, elicitation, analysis, specification, validation, specification, and management of the requirements.

Requirement Engineering Activities

• Inception kicks off process with identification of a business need, new market opportunities and great ideas.
• Requirements elicitation discovers requirements through consulting with stakeholders.
• Requirement analysis and negotiation analyzes requirements and resolves conflicts.
• Requirements specification produces the requirements documents.
• Requirements validation checks for the requirements documents completeness and consistency.
• Requirements management evolves with the contexts and current needs.

Requirement Inception

• It starts the process involving identifying the business needs, a new market opportunity or perhaps just a great idea.
• This involves building a business case including preliminary assessment of feasibility and definition of the scope of project.
• It involves stakeholders like business managers, marketing, and product managers using brainstorming, Joint Application Development (JAD), meeting etc.

Requirement Elicitation

• It focuses on gathering information related to the problem domain, problems requiring solutions, and constraints related to the problem or solution.
• It involves answering the questions of the nature and goals of a system, how is the work done and what are the problems, or how the solution affects daily usages.
• This can be challenging because customers may not be able to describe their needs and software engineers may struggle with the concerns.
• Different backgrounds and terminologies between software engineers and customers leads to difficulties.
• Volatility and the change of requirements over time makes it difficult.
• Techniques include brainstorming, moderated meetings, interviews, task observation, use cases, scenarios or questionnaires.

Requirement Analysis

• Requirement analysis studies and analyzes the needs of stakeholders.
• Objective can be to solve the problem with a new workflow, new system, or new software.
• Objectives involve detecting/resolving conflicts (through negotiation), discovering a boundary, or elaborating system requirements.

Requirement Specifications

• Requirement specification invents and defines the behavior of the new proposed system in detail.
• Requirement specification describes the software system and defines its problem domain effects.
• A Software Requirements Specification Document (SRS) describes the essential requirements such as functions, performance, constrains, quality, interfaces etc.
• It establishes the basis for agreements between the customer and contractors on the expectations of features and rigorous assessment of requirements.

Requirement Validation and Verification

• Validation and verification ensure delivery of the clients wants and needs during project.
• They involve needs, and both are to be performed at every stage in the process.
• Validation checks the right product versus the stakeholders and customer goals.
• Verification check product is built right while referring to the specification of the system during the design phase.

Requirement Management

• Necessitates dealing with changes to the requirements caused by business process changes, technology, and understanding the problem.
• Traceability is important for effective requirements management.

Requirements Documents

• Vision and Scope Documents
• Elicitation notes which often contain raw unstructured requirements
• Problem Domain requirements documents
• System and Software requirements documents.

Types of Requirements Documents

• Informal outlines using paragraphs and diagrams or requirements definitions.
• Containing specifications with thousands of intricate pages describing in detail.
• The requirements specification documents for large systems are normally arranged in a hierarchy.

Challenges of Requirements Process

• Lacking domain expertise, skills and experience.
• Initial ideas are often optimistic and incomplete
• Difficulty of using complex tools may negate the anticipated benefits of a complete approach

Statistics of NIST Report

• 70% of defects are initiated during the specification phase.
• 30% of defects are introduced during the technical solution process.
• 5% of specification inadequacies are corrected in the specification phase.
• 95% of faults are detected later in the project/delivery with a correction that amounts to 22 times higher in cost.
• Extensive testing is essential to detect specification errors late in the process.

Categories of Requirements

• Business requirements; what the business needs.
• User requirements; what the users need to do.
• Functional requirements; what the software should do.
• NFR (Non-Functional Requirement); list of characteristics the system should have.

Business Requirement

• Business requirements are what delivers value, such as increasing market share, shorten order processing time, reduce customer service costs.
• Success is measured by whether the stated business requirements are achieved.

User Requirements

• User defines what the system can perform, such as determining available credit or look up account balances.

Functional Requirements

• Functional Requirements that define a system as a product that defines its use.
• These are how the system supports user requirements and how the system relates to the system's processes.

Non-Functional Requirements (NFR)

• These requirements define important aspects of a process in the system.
• These are the required components; performance, usability, efficiency, reliability, maintainability etc.
• Requirements cannot be met if the system is useless or difficult to verify.
• They are also called quality, services, or other extra features.

Non-Functional Requirements Types

• Performance requirements: this includes throughput and response time
• Design constraints: categories regarding technology or the environment.
• Commercial constraints: categories in the project plan such as cost and date of delivery.
• NFR's important to users include security and compatibility.
• NFR's important to developers include maintainability and testability.
• Performance helps quantify the time and attributes of the system.
• Dependability allows the system to act as a reliable service for robustness and safety.
• Sommerville's Classification include product, external and organizational requirements shown by diagram.

NFR examples

• The product ports to Linux.
• Easy to use with one hand.
• Usable with poor lighting.
• Can Identify aircraft with 0.25 seonds.
• Complies with process and deliverables defined in XYZCOSPSTAN95.
• Disclosure of personal information limited to name and reference number.

Types of measurements

• Speed is measured is processed transactions/second.
• User/Event response time, screen refresh time.
• Reliability is measured in mean time to failure.
• Availability is the average time a system is operational.

Identification of NFR and Requirements

• Breaking down requirements into tasks and tasks can help identify what the overall goals of a system are.
• E-Commerce system example includes security, performance, usability.
• Functional vs non-functional aspects should be understood.
• Discussions with all stakeholders in order to elicit their requirements based on their individual perspectives of the process

The Source of Requirements

• Discussions with stakeholders to the elicit their individual insights during process.
• Analysis of competing systems.
• Policy and Procedure Manuals for the business and process extracted form customer surveys.
• Legacy systems containing system manuals and specifications.

Requirements Characteristics

• The characteristics include: clear, correct, consistent, coherent, comprehensible, modifiable, verifiable, prioritized, unambiguous, traceable, and credible.
• Example of a restaurant advisor system
• There must be solutions and suggestions on improving processes
• Ambiguity in "reservation database" and "automated reservation system" requires better definition and clarity

Examples of Functional Requirements for Amazon.ca include

• Search to enable user to find an item based on characteristics.
• Browse to find the customer an item.
• Enable the users to shop and purchase items with access to other user feedback.

Non-Functional includes

• Operational - system should work on any web browser.
• Performance - System should be operationable and available every minute of every day.
• Registered customers need to be able to review their own accounts.
• The presence of multiple languages for multi-cultural adaption

Modeling

• Model the requirements from the Requirements Engineering processes to improve understanding.
• Models can be graphical, textual, or mathematical.
• System engineering uses various modeling techniques such as Environmental Model or Behavioral Model.
• Development with structures involve models and structured flows, while object-oriented modelling has use-cases.

Models

• Models are a set of textual, graphical, or mathematical descriptions of a system.
• Textual models describe written down scenarios.
• Graphical models include schematic or diagram representations.
• Mathematical models use formulas and stats.