System Requirements Engineering

• System requirements describe system services and constraints generated during the requirements engineering process.
• Requirements range from high-level statements of service or system constraints, to detailed mathematical functional specifications.

Requirements Engineering (RE) Processes

• RE processes widely vary depending on the application domain.
• Generic activities common to all processes:
  • Requirements elicitation
  • Requirements specification
  • Requirements validation
  • Requirements management
• RE is an iterative activity where processes are interleaved.

Requirements Elicitation and Analysis

• Sometimes called requirements discovery.
• Involves technical staff working with customers to understand the application domain, system services, and operational constraints.
• May involve stakeholders such as end-users, managers, engineers involved in maintenance, domain experts, and trade unions.

Requirements Elicitation Techniques

• Traditional methods:
  • Interviewing and Listening
  • Interviewing Groups
  • Survey/Questionnaire
  • Ethnography
  • Analyzing procedures and other documents
• Modern Methods:
  • Joint Application Design (JAD)
  • CASE tools
  • Prototyping

Interviews

• Interviews with stakeholders are part of the requirements elicitation process.
• Types of interviews:
  • Closed interviews: use a pre-determined list of questions.
  • Open interviews: explore various issues with stakeholders.
• Effective interviewing involves being open-minded, prompting discussion, and mixing closed and open-ended questions.

Problems with Interviews

• Application specialists may use language not easily understood by requirements engineers.
• Interviews are not ideal for understanding domain requirements if engineers lack specific domain terminology.
• Domain knowledge may be too familiar for people to mention or consider worth discussing.

Group Interviews

• Several key people are interviewed together.
• Several analysts could be involved.
• Advantages:
  • More efficient use of time.
  • Allows hearing agreements and disagreements at once.
• Disadvantage:
  • More difficult to schedule than individual interviews.

Ethnography

• Involves spending considerable time observing and analyzing how people work.
• People do not have to explain their work.
• Effective for understanding existing processes but cannot identify new features.
• Ethnography studies existing practices, some of which may have historical bases and no longer be relevant.

Nominal Group Technique (NGT)

• A facilitated process that supports idea generation by groups.
• Process:
  • Members come together but work separately to write down ideas.
  • A facilitator reads the ideas aloud, and they are written down.
  • The group then discusses and prioritizes the ideas.
• In the context of requirement determination, NGT applies to problems with existing systems or ideas for new features.
• The final result is a prioritized list of problems or features generated by group members.

Survey/Questionnaire

• Used to collect business analysis information about customers, products, work practices, and attitudes from a group of people in a structured way in a short period of time.
• Types of questions:
  • Close-ended: easier to analyze due to numerical ties.
  • Open-ended: useful when issues are known but the range of user responses is not; more difficult and time-consuming.
• Relatively inexpensive to administer.
• Easier to collect data from a larger audience.
• Does not typically require significant time.
• Suitable for geographically dispersed stakeholders.
• Effective for obtaining quantitative data for statistical analysis.
• Results may yield insights and opinions.

Survey/Questionnaire Limitations

• Achieving unbiased results requires specialized skills in statistical sampling methods.
• Low response rates will affect statistical significance.
• Open-ended questions may require more analysis.
• Ambiguous questions may go unanswered or answered incorrectly.
• May require follow-up questions or more survey iterations.

Modern Methods for Determining Requirements

• Joint Application Design (JAD):
  • Brings together key users, managers, and systems analysts.
  • Gathers system requirements simultaneously from key stakeholders.
  • Conducted off-site.
• CASE tools:
  • Used to analyze existing systems.
  • Help discover requirements to meet changing business conditions.
• System prototypes:
  • Iterative development process.
  • Basic working version of a system is built.
  • Refines understanding of system requirements in concrete terms.

Joint Application Design (JAD) Details

• JAD is a requirement determination technique focusing on groups
• It is purposed to collect system requirements simultaneously involving key stakeholders like users, managers, and system analysts.
• Team members meet in isolation for an extended period.
• Usually conducted at a separate location.
• JAD is highly focused.
• The result is an intense, structured, and highly effective process.
• JAD offers an opportunity to resolve conflicts or understand why a conflict is not easily resolved.

JAD Participants

• Session Leader- Facilitates group process, manages groups, sets agenda, remaining impartial, resolves conflicts and disagreements.
• Users- Active, speaking participants.
• Managers- Active, speaking participants.
• Sponsor- High-level champion, limited participation.
• Scribe- Records session activities (word processor, CASE tool).
• System Analysts- Should mostly listen.
• IS Staff- Should mostly listen.

Joint Application Design Final Results

• End Result:
  • Documentation detailing the existing system.
  • Features of the proposed system.
• CASE Tools During JAD:
  • CASE tools are used.
  • It enables analysts to enter system models directly into CASE during the JAD session.
  • In a JAD Session, Screen designs and prototypes shown to users.

Prototyping Details

• Used to elicit and validate stakeholder needs through an iterative process.
• Creates a model or design of requirements.
• Optimizes user experience and to evaluate design options.
• Serves as a basis for the final business solutions development.
• Quickly converts requirements to working version of system.
• Once the user sees requirements converted to a system, they can ask for modifications or will generate additional requests

Prototyping Usefulness

• Most useful when: -User requests are unclear
  • Few users are involved in the system
  • Designs are complex and require concrete form
  • Provides visual representation of current date -Allows giving input\ feedback earlier in in design process
  • History of communication issues between analysis and users
  • Tools are readily available to build prototype.

Prototyping Drawbacks

• Difficult to adapt to a more general user audience.
• Technology should be understood to initiate prototyping.
• Unrealistic expectations for the final solution.
• Higher expectations of performance, reliability, and usability.
• Focus on the solutions design specification rather than non-functional requirements.

Problems of Requirements Elicitation

• Stakeholders may not know what they want.
• Stakeholders express requirements in their own terms.
• Different stakeholders may have conflicting requirements.
• Organizational and political factors may affect system requirements.
• The requirements may change during the analysis phase.
• New stakeholders may emerge.
• Changing business environment.

Requirement Specification

• Writing down users and system requirements.
• Requirements document needed.
• Requirements may be part of a contract for system development
• These notes must be as complete as possible.

Methods of Writing Requirements

• Natural Language: Requirements written using numbered sentences, with each sentence expressing on requirement
• Structured - Writing down the requirements in natural language using a standard template.
• Design description languages - Using languages such as a programming language with added abstract features to dictate requirements. Rarely used, but beneficial for interface specifications.
• Graphical notations - Using graphical models and text annotations to dictate the functions of the system. Commonly seen with UML.
• Mathematical specifications - These notations are based on mathematical concepts such as finite-state machines or sets. Can reduce ambiguity however that also means most customers do not understand.

Natural language Specification

• Requirements written as natural language sentences supplemented by diagrams and tables.
• Used for writing requirements because it is expressive, intuitive, and universal.
• This means that the requirements can be understood by users, customers, and managers.

Problems with Natural language

• Lack of clarity. Precision is difficult.
• Requirements confusion - Functional and non-Functional requirements tend to be mixed-up.
• Requirements combination - Several different requirements may be expressed together.

Structured Specifications

• When the freedom of the creator is limited, that is, requirements are to be written in a standard way.

Structured Specification Elements

• Definition of the function.
• Description of inputs (and where they come from).
• Description of outputs (and where they go to).
• Information needed for the computation.
• Description of the action to be taken.
• Pre- and post-conditions (if appropriate).
• The side effects (if any) of the function.

Software Requirements Specification (SRS) Document

• This document is the standard requirement of what the system developers need.
• It should include the definition of user requirements and a specification of the system requirements.
• Used by system customers, managers, developers, engineers, testers, and maintenance engineers.
• The main aim of determining the information requirements of an organization by analysts is to prepare a precise SRS understood by user.

SRS Template Components

• Introduction- This section describes the need for the system, its functions, and also how it will work with other systems
• Context Diagram- Identifies the flows of information between the system and external entities.
• User Requirements - The requirements of the user written in their own language.
• Fuctional Requirments - Describes the software system and it lists them in ranked order. Each requirement has it's own format.
• Non-Fuctional Requirements - Specifies requirements and attributes required by the system such as interface requirements, performance requirements, or reliability requirements.

Graphical Notation: Use Cases

• Use-Cases are a kind of scenario in the UML.
• High-level graphical model supplemented by more detailed tabular description.
• Use cases identify the actors in an interaction and describe the interaction itself.
• UML sequence diagrams may be used to add detail by showing the sequence of event processing in the system.

Requirements Validation

• Demonstrating that the requirements define the system.
• Requirement error costs are high so validation is very important.
• Fixing an error after delivery can 100x cost to implement,

Requirements Management

• Managing changing requirements.
• Track individual requirements.
• maintain links between dependent requirements for assessing the impact of requirements changes.