Requirement Engineering Fundamentals

Requirement Engineering

• Requirement engineering is the most critical step of the entire Software Development Life Cycle (SDLC).
• Making changes is easier during this stage.
• Most system failures are linked to problems in the requirements.
• Iterative processes ensure that small batches of requirements can be identified and implemented incrementally, allowing the system to evolve.

Purpose of Requirement Engineering

• Converts high-level business requirements from the system request into detailed software requirements.
• The detailed software requirements serve as inputs for creating models.

Requirements

• It is a statement of what the system must do or a characteristic it must have.

Requirement Types

• Functional requirements relate to a process or data.
• Non-functional requirements relate to performance or usability.

Sample Functional Requirements

• The user must be able to register.
• The admin must be able to delete accounts.
• The parent must be able to print a student progress report.

Sample Non-Functional Requirements

• The system must run on Linux.
• The system must interoperate with Edugate.
• The user must be able to complete operations within no more than 5 mouse clicks.
• The system must be available 99.9% of the time.

Operational Nonfunctional Requirements

• Technical environment is part of operational requirements.
• System integration is part of operational requirements.
• Portability is part of operational requirements.
• Maintainability is part of operational requirements.

Cultural Influence

• Customization requirements like language differences are part of cultural influence.
• Legal requirements are part of cultural influence.

Performance Criteria

• Speed is a performance criterion.
• Capacity is a performance criterion.
• Availability and reliability are performance criteria.

Operational Technical Environment Requirements

• The technical environment consists of special hardware, software, and network requirements imposed by business requirements.
• An example is that the system may work over the Web environment with Internet Explorer

Operational System Integration Requirements

• The extent to which the system will operate with other systems.
• An example includes the system must be able to import and export Excel spreadsheets.

Operational Portability Requirements

• The degree to which the system can operate in different environments.
• For example, the system must be able to work with different operating systems like Linux, Mac OS, and Windows.

Operational Maintainability Requirements

• The expected business changes the system should adapt to.
• New versions of the system may be released every 6 months.

Performance Speed Requirements

• This is the time within which the system must perform its functions.
• Response time must be less than 7 seconds for any transaction over the network.

Performance Capacity Requirements

• Encompasses the total and peak number of users and the volume of data expected.
• There will be a maximum of 100-200 simultaneous users at peak use times.

Performance Availability and Reliability Requirements

• Relates to the extent to which the system will be available to users and the permissible failure rate due to errors.
• The system must have 99% uptime performance.

Customization Requirements

• A way of tailoring aspects of the system, that can be changed by local users.
• An example is country managers being able to define new fields in the product database to capture country-specific information.

Legal Requirements

• Consists of laws and regulations that impose requirements on the system.
• Personal information about customers cannot be transferred out of European Union countries into the United States.

Security System Value Estimates

• An estimated business value of the system and its data.
• A system outage is estimated to cost $50,000 per hour in lost revenue.

Security Access Control Requirements

• Limitations on who can access what data.
• Only department managers can change inventory items within their own department.

Security Encryption and Authentication Requirements

• Defining what data will be encrypted.
• Where and whether authentication will be needed for user access.
• Data will be encrypted from the user's computer to the website to provide secure ordering.

Virus Control Requirements

• Requirements to control the spread of viruses.
• All uploaded files will be checked for viruses before being saved in the system.

Requirement Engineering Process Phases

• Requirement elicitation involves gathering and determining requirements.
• Requirement analysis involves analyzing all requirements
• Requirement specification involves defining requirements.
• This process is concurrent, iterative, and incremental.
• Business and IT personnel must collaborate.

Requirement Elicitation

• Requirement elicitation uncovers all requirements; requirements uncovered late are harder to incorporate.

Elicitation Techniques

• Interviews.
• Joint Application Development (JAD).
• Questionnaires.
• Document analysis.
• Observation.

Interviews for Elicitation

• An interview is the most popular elicitation technique that helps you know something by asking.
• The process includes selecting people to interview and creating a schedule.
• Designing interview questions with open-ended, closed-ended, and probing question types.
• Preparing for the interview and conducting it in a logical order.
• Following up after the interview.

Interview Question Types

• Closed-ended questions lead to short and precise responses.
• Open-ended questions encourage detailed answers.
• Probing questions seek examples and greater detail.

Interviewing Strategies

• Top-down interviewing begins with general questions and moves to specific ones.
• Bottom-up interviewing starts with specific questions and moves to broader ones.

Post-Interview Actions

• Prepare notes and send them to the interviewee for verification.

Joint Application Development (JAD)

• A JAD is a joint user-analyst meeting.
• Meetings can be held electronically and anonymously to reduce problems in group settings.
• JAD can be accomplished remotely, but sessions require careful planning, and users may need documents or user manuals.

Questionnaires for Elicitation

• A questionnaire is a set of written questions used to obtain information from individuals.
• It may be paper-based or electronic.
• These are commonly used to reach many people, gather different information or opinions, and solicit feedback from customers or vendors

Questionnaire Steps

• Select participants and identify the population and use samples for large demographic areas.
• Design the questionnaire, select questions carefully, and remove ambiguities.
• Administer the questionnaire to get a good response rate and offer an incentive.
• Follow up on the questionnaire and send results to participants, with a 'thank you'.

Good Questionnaire Design Practices

• Start with non-threatening and interesting questions.
• Group questions into logically consistent sections.
• Avoid putting the most important items only at the end.
• Avoid crowding a page with too many items.
• Avoid abbreviations and biased or suggestive items or terms.
• Number questions to avoid confusion.
• Pretest to identify confusing questions while assuring anonymity to respondents.

Document Analysis for Elicitation

• Document Analysis provides information about the "as-is" system.
• Review technical and typical user documents, such as forms, reports, and policy manuals.

Observation

• Observation involves watching processes being performed to gain insight into the current system.
• It should enable the analyst to see the reality of a situation, rather than listening to others describe it.
• It also checks the validity of information that has been previously gathered.
• Avoid interrupting or influencing workers.

Comparing Elicitation Techniques

• Combining techniques is generally beneficial.
• Document analysis and observation need minimal training, but JAD sessions can be challenging.

Alternative Elicitation Techniques

• Concept Maps
  • These represent relationships between concepts
  • Focus individuals on key details.
• User Stories, Story Cards & Task Lists
  • Used in Agile development methods.
  • Capture stories using index cards.
  • They capture functional and nonfunctional requirements.

Story Cards & Task Lists

• Captures a requirement using story cards which relates to index cards.
• Consists of a file card with a single requirement.
• Each requirement or card, is discussed.
• Determines how much effort to implement.
• Creates a task list for each requirement which are often written done in stories.
• Large requirements can be split into smaller sections and prioritized by risk level and importance.

Requirement Analysis Problems

• May occur because the analyst might not have access to the correct users.
• Ambiguity.
• Contradiction.
• Incompleteness.
• Incompatibility.

The System Proposal

• Combines all material created in planning & analysis.
• Includes the following sections:
  • Executive summary.
    • Provides all critical information in summary form.
    • Helps busy executives determine which sections they need to read in more detail.
  • The system request.
  • The workplan.
  • The feasibility analysis.
  • The requirement definition.
  • Current models of the system (expected to evolve).
  • Appendices.

System Proposal Template contents

• Table of Contents
• Executive Summary
• System Request
• Workplan
• Feasibility Analysis
• Requirements definition
• Functional Model
• Structural Models
• Behavioral Models.
• Appendices