Unit 2: Requirements and design
Software Engineering notes · PTU syllabus (PGCA1912)
On this page
- Unit summary
- Understanding requirements
- Requirements engineering tasks
- Building the analysis model
- Flow-oriented modelling: data flow diagrams
- Scenario, class and behavioural models in UML
- The design process
- Design concepts
- The design model
- Data and architectural design
- Key terms
- Quick revision
- Important questions
Unit summary
Requirements define what to build; design decides how. This unit covers requirements engineering, understanding requirements, building the analysis model, the design process and design concepts, and the design model — data, architectural, interface, component-level and deployment-level design elements.
After this unit you can
- Explain requirements engineering tasks
- Build analysis models
- Apply design concepts
- Describe the elements of the design model
PTU syllabus topics
- Requirements engineering and understanding software requirements
- building the analysis model
- the design process and concepts
- the design model — data
- architectural
- interface
- component-level and deployment-level design elements
Data design
Data structures and databases
Architectural design
Overall structure
Interface design
UI and system interfaces
Component-level design
Internal logic of modules
Deployment design
Hardware and environment
Topic 1
Understanding requirements
Describes
What the system must do
How well it must do it
Examples
"Student can register for a course"; "System generates a fee receipt"
Response under 2 seconds; 99.9% availability; data encrypted
Testing
Tested by functional tests
Tested by performance, security, usability tests
A Software Requirements Specification (SRS) documents all requirements. A good SRS is correct, unambiguous, complete, consistent, verifiable, modifiable and traceable.
Topic 2
Requirements engineering tasks
- 1
Inception
Understand the problem and stakeholders
- 2
Elicitation
Interviews, questionnaires, observation, workshops, use cases
- 3
Analysis and negotiation
Resolve conflicts, prioritise
- 4
Specification
Write the SRS
- 5
Validation
Reviews, prototypes, test-case generation
- 6
Management
Track changes with traceability
Exam tip
Requirements must be validated with the customer before design — fixing a requirement error after delivery can cost many times more than fixing it early.
- Collaborative requirements gathering
- Joint meetings of customers and developers
- Quality function deployment (QFD)
- Normal, expected and exciting requirements
- Usage scenarios
- Use cases describing how actors use the system
- Elicitation work products
- Statement of need, scope, stakeholder list, scenarios, prototypes
Topic 3
Building the analysis model
Scenario-based
Use cases, use-case diagrams, activity and swimlane diagrams
Class-based
Class diagrams, CRC (class–responsibility–collaborator) cards
Behavioural
State diagrams, sequence diagrams
Flow-oriented
Data flow diagrams, control flow, process specifications
- Analysis rules of thumb: focus on visible requirements, keep abstraction high, add value for all stakeholders, minimise coupling, keep the model simple.
Topic 4
Flow-oriented modelling: data flow diagrams
- DFD: models how data moves and is transformed; drawn top-down as a context diagram (level 0) refined into level 1 and level 2.
- External entity (rectangle)
- Producer or consumer outside the system
- Process (bubble)
- Transformation of data
- Data flow (arrow)
- Data in motion
- Data store (parallel lines)
- Data at rest
- Rules: every process has at least one input and output; data cannot flow directly between two entities or two stores; balance flows between levels; number processes 1.0, 1.1 and so on.
Example
Library context diagram: entities Member and Librarian exchange issue requests, return details and reports with the single process "Library Management System".
Topic 5
Scenario, class and behavioural models in UML
| Diagram | Shows |
|---|---|
| Use case diagram | Actors and the functions (use cases) they use |
| Class diagram | Classes, attributes, operations and relationships |
| Sequence diagram | Messages between objects in time order |
| Collaboration (communication) diagram | Object interactions, focusing on links |
| Component diagram | Physical software components and their interfaces |
Example
Use case diagram for a library: actors Student and Librarian; use cases Search Book, Issue Book, Return Book, Pay Fine.
Topic 6
The design process
- Design translates the analysis model into a blueprint; it is iterative, moving from high abstraction to detail.
- Architecture
- Recognisable styles and patterns, built from components
- Modularity
- Logically partitioned into elements
- Distinct representations
- Data, architecture, interfaces, components
- Appropriate data structures
- For the classes to be implemented
- Independent components
- Functional independence
- Simple interfaces
- Reduced complexity of connections
- Repeatable method
- Driven by requirements analysis
- Effective notation
- Communicates meaning clearly
Topic 7
Design concepts
Design quality guidelines: a design should implement all requirements, be readable and understandable, and give a complete picture of data, functions and behaviour.
- Abstraction
- Focus on essentials, hide detail
- Architecture
- Overall structure of components
- Modularity
- Divide software into separately named modules
- Information hiding
- Modules hide internal details
- Functional independence
- High cohesion, low coupling
- Refinement
- Step-wise elaboration of detail
Exam tip
High cohesion (each module does one thing well) and low coupling (modules depend little on each other) is the mark of good design.
Topic 8
The design model
- Deployment-level design
How software and subsystems are allocated to physical computing nodes (deployment diagram)
- Component-level design
Internal detail of each component — algorithms, data structures, interfaces
- Interface design
User interface, external interfaces to other systems, internal interfaces between components
- Architectural design
Overall structure — styles, subsystems and their relationships
- Data design
Data structures, database and data warehouse design from the data model
Topic 9
Data and architectural design
Software architecture is the structure of a system: its components, their properties and relationships. Common styles: data-centred, data-flow (pipe and filter), call-and-return, layered, object-oriented and client-server. Data design turns the data model from analysis into data structures and database designs.
Key terms
- Requirements engineering
- Tasks to understand and document what the customer needs
- Use case
- Description of how an actor interacts with the system
- CRC card
- Index card listing a class, its responsibilities and collaborators
- Design model
- Blueprint with data, architectural, interface, component and deployment elements
- Deployment diagram
- UML view of software placed on hardware nodes
Quick revision
- Functional and non-functional requirements; SRS qualities.
- Inception, elicitation, elaboration, negotiation, specification, validation, management.
- Scenario, class, behavioural and flow models; DFD; UML diagrams.
- Design guidelines and concepts: abstraction, architecture, patterns, modularity, information hiding, functional independence, refinement.
- Data, architectural, interface, component and deployment design.
Important exam questions
Practice questions written to the PTU exam pattern for this unit's syllabus: short answers (Section A style) and long answers (Sections B and C style).
Short-answer questions
- Q1.Distinguish functional and non-functional requirements.
- Q2.What is QFD?
- Q3.Name the elements of the analysis model.
- Q4.What is a CRC card?
- Q5.Distinguish cohesion and coupling.
- Q6.What does a deployment diagram show?
Long-answer questions
- Q1.Explain requirements engineering tasks.
- Q2.Explain how the analysis model is built.
- Q3.Explain the design process and design concepts.
- Q4.Explain the elements of the design model.
Stuck on this unit?
Message SBS on WhatsApp for help with Software Engineering, or to ask about studying M.Sc IT at Synetic.