Requirements Engineering Tutorial

Requirements Engineering Tutorial

Requirements engineering tutorial discusses a series of recommended exercises on how to gather, write, validate, and organize requirements. It intends to introduce the best notions from various techniques and arrange them into a consistent piece. This tutorial is only a guideline to overview various parts of requirements engineering on a general level.

Requirements engineering is described as the process of defining, recording, and securing requirements to the sub-fields of systems engineering and software engineering associated with this process.

The first time the term requirements engineering was used goes back to in 1979 in a TRW technical report, but it didn’t start the general use of this concept until in the 1990s in the publication of an IEEE Computer Society tutorial.

In the waterfall model, requirements engineering is demonstrated as the first stage of the development process. Then software development methods, consisting of the Rational Unified Process (RUP), extreme programming (XP) and Scrum postulate that requirements engineering remains across the lifetime of a system. Alan M. Davis keeps a broad bibliography of requirements engineering.

Moreover, requirement management, a sub-function Systems Engineering, approaches are also added to the INCOSE (International Council on Systems Engineering) manuals.

Requirements Engineering (RE) Process

The processes used for RE differ broadly based on the used domain, the people engaged and the organization creating the requirements. However, there are a number of general activities:

• Requirements elicitation
• Requirements analysis
• Requirements validation
• Requirements management

Feasibility Studies

• A feasibility study determines if the proposed system is valuable
• A short attentive study that authorizes:
  • If the system participates in organizational objectives
  • If the system can be engineered by the existing techniques and within the budget
  • If the system can be incorporated into other systems that are already used
• Feasibility study establishment varies with data evaluation (what is necessary), information gathering, and reporting
• Questions for the people in the corporate:
• How things were different if the system wasn’t employed?
• What are the present issues in the process?
• How will the projected system help resolving these issues?
• What will be the incorporating issues?
• Is a new technique required? How about new skills?
• What facilities will be brought into that the proposed system should support?

Elicitation and Analysis

• Often called requirements elicitation or requirements discovery
• Engages technical personnel who work with clients to discover about the application domain, the services that the system should offer and the system’s operational constraints.
• May engage stakeholders: end-users, managers, engineers participating in maintenance, domain experts, trade unions, etc.

Issues with Elicitation

• Stakeholders often don’t really know what they want
• Stakeholders express requirements in their own language
• Diverse stakeholders may have contradictory requirements
• Organizational and political factors might affect the system requirements
• The requirements vary over the evaluation process. New stakeholders may develop and the entire business environment change

Requirements Elicitation and Analysis Process Activities

• Requirements discovery
  • Communicating with stakeholders to realize what their actual requirements are.
  • Domain requirements are also discovered at this stage
• Requirements category and organization
  • Various groups relate and organize requirements into coherent clusters
• Prioritization and negotiation
  • Prioritizing requirements and solving requirements conflicts
• Requirements documentation
  • Requirements are recorded and put into the next round of spiral

Requirements Discovery

• The process of collecting data about the projected and the current systems and extracting the user’s and system’s requirements from the collected information
• Sources of data consist of documentation, system stakeholders and the specifications of similar systems

Viewpoints

• Viewpoints are a way of arranging the requirements to demonstrate the perspectives of various stakeholders.
• Stakeholders could be categorized based on various viewpoints.
• This multi-perspective analysis is crucial as there is no only proper approach to assess system requirements.
• Communicative viewpoints
• Indirect viewpoints
• Domain viewpoints

Viewpoints Identifies:

• Providers and receivers of system services
• Systems that communicate with the system being targeted
• Regulations and standards
• Sources of business
• Non-functional requirements
• Engineers who are responsible to create and secure the system
• Marketing and other business viewpoints

Use Cases

• They are defined based on a scenario approach in the UML that determines the actors in a relationship and explains the relationship itself.
• A series of use cases should define all possible connections with the system.
• Sequence diagrams could be applied to supplement detail to use-cases by demonstrating the sequence of event processing in the system.

Social and Organizational Factors

• Software systems are applied in a social and organizational framework. This can impact or even control the system requirements.
• Social and organizational factors are not a specific viewpoint but are effects on all viewpoints.
• Good analysts are thoughtful to these factors but presently no structured approach to challenge their analysis.

Requirements Validation

• Illustrates the requirements for the system that really a customer wants
• Requirements error are expensive so validation is crucial
• Fixing an error in the requirements once it is delivered could cost up to 100 times the cost of fixing an implementation error
• Requirements Checking:
  • Validity
  • Coherency
  • Completeness
  • Applicability
  • Verifiability

Requirements Validation Approaches

• Requirements reviews
• Prototyping
• Test-case generation

Requirements Reviews

• Performing consistent reviews while formulating the requirements definition
• Engaging both client and contractor staff in reviews
• There two forms of formal and informal reviews
• Effective communications among developers, customers and users can help identifying and fixing issues at early phases
• Review checks:
  • Verifiability
  • Clarity
  • Traceability
  • Flexibility

Requirements Management

• Requirements management is the practice of managing the changing requirements through the process of the requirements engineering and system development
• Requirements are unavoidably imperfect and variable
• Requirements change:
  • The importance of requirements from diverse viewpoints varies through the development process.
  • System customers might identify requirements from a business standpoint that disagrees with end-user requirements.
  • The business and technical conditions of the system varies during its development.

Enduring and Volatile Requirements

• Enduring requirements
  • Steady requirements developed from the essential activity of the customer organization
• Volatile requirements
  • Requirements that vary through development or when the system is in operation

Requirements Management Planning

During the requirements engineering process, you have to plan:

• Requirements detection
• A change management process
• Traceability process
• CASE tool support

Requirements Change Management

• All the suggested and projected modifications should be applied in the requirements.
• Major Phases:
  • Assessing the problems
  • Changing the expenses and evaluation
  • Changing execution

How Can You Learn More About Requirements Engineering?

TONEX offers hands-on training courses among which you can find what serves your needs best:

Requirements Engineering Training Workshop

Requirements Engineering Management Training

Requirements Engineering Workshop with Use Cases

Requirements Engineering Training | Workshop

Requirements Engineering Training

Requirements Engineering Tutorial