Software Engineering Requirements & UML: Key Concepts and Techniques quiz 2

Requirements elicitation

Collecting requirements from stakeholders

Requirements analysis

Modeling desired behavior for better understanding

Requirements specification

Defining requirements in clear language

Requirements validation/verification

Verifying specified requirements

Software Requirements Specification (SRS)

Final outcome document of the requirements process

Clients

Pay for software development

Customers

Buy software after development

Users

Actually use the system

Domain experts

Familiar with the problem area

Market researchers

Determine trends and potential customers

Lawyers/auditors

Know legal/safety requirements

Software engineers

Technology experts

What questions

Lead to facts about the problem

Why questions

Reveal deeper motivations and problem structure

How/Where/When questions

Provide process details

Could questions

Maximally open, might lead to useful insights

Good interview practices

Ask open-ended questions instead of yes/no questions

Focus on problems

Customers don't know the technical solution

Don't ask leading questions

Avoid suggesting answers

Ask 'obvious' questions

Don't make assumptions

Use putative questions

Test your understanding of the domain

Allow periods of silence

Give stakeholders time to think

Functional Requirements

State what the system should do, describing system behavior and services.

Non-Functional Requirements

Describe constraints on the system, including quality attributes like performance, security, portability, and scalability.

Invariant Requirements

Conditions that always hold true, critical for safety systems.

Characteristics of Good Requirements

Cohesive, complete, consistent, unambiguous, and verifiable.

Cohesive

Addresses only one system property.

Complete

Fully stated with no missing information.

Consistent

Doesn't contradict other requirements.

Unambiguous

Clear to any reader.

Verifiable

Can be demonstrated, measured, tested.

Common Problems to Avoid

Mixing functional and non-functional requirements, including implementation details, using vague terms, and non-verifiable statements.

Writing Tips

Use 'shall' for verifiable requirements, provide context and quantifiable measures, break complex requirements into atomic elements, and specify acceptable error bounds and conditions.

Unified Modeling Language (UML)

A tool to visualize, specify, construct, and document a system.

Structural Diagrams

Static aspects of UML including Class Diagram, Interface Diagram, Object Diagram, Component Diagram, and Deployment Diagram.

Behavioral Diagrams

Dynamic aspects of UML including Use Case Diagram, Sequence Diagram, Collaboration Diagram, Statechart Diagram, and Activity Diagram.

UML Development Process

Steps include capturing requirements, identifying objects/relationships, creating usage scenarios, generalizing behavior, and adding implementation details.

Actor

External entity that interacts with the system.

Component

Physical grouping of elements such as classes and interfaces.

Node

Computational resource that exists at runtime.

Use Case

High-level service or goal from the user perspective.

Class Diagram

Illustrates classes and their relationships.

Interface Diagram

Specifies operations that define class services.

Object Diagram

Shows objects and their relationships.

Component Diagram

Represents physical realization of logical groupings.

Deployment Diagram

Depicts nodes and relationships at runtime.

Use Case Diagram

Organizes system behaviors from an external perspective.

Sequence Diagram

Focuses on the time ordering of messages.

Collaboration Diagram

Focuses on the structural organization of message-sending objects.

Statechart Diagram

Illustrates changing states driven by events.

Activity Diagram

Shows flow of control between activities.