1. Software Requirements and Specification 14 Marks
A software requirement is a statement describing a service, feature, behavior, constraint or quality that a software system must provide.
Types of Requirements
Functional requirements: Describe what the system must do.
Non-functional requirements: Describe quality attributes such as security, performance and reliability.
Domain requirements: Arise from the application domain, laws or business rules.
User requirements: High-level requirements written for customers and users.
System requirements: Detailed technical description for developers.
Requirements Engineering Process
Feasibility Study
|
v
Requirement Elicitation
|
v
Requirement Analysis
|
v
Requirement Specification
|
v
Requirement Validation
|
v
Requirement Management
Importance
Creates a common understanding between customer and developer.
Provides the basis for design and testing.
Reduces rework and project failure.
Helps estimate cost, effort and schedule.
Controls project scope.
2. Feasibility Study 14 Marks
A feasibility study evaluates whether a proposed software project is practical, beneficial and achievable within available constraints.
Types of Feasibility
Technical feasibility: Availability of technology, tools and technical skills.
Economic feasibility: Whether expected benefits justify total cost.
Operational feasibility: Whether the system will work effectively in the organization.
Schedule feasibility: Whether the project can be completed within the required time.
Legal feasibility: Compliance with laws, licenses, contracts and data rules.
Organizational feasibility: Compatibility with business strategy and organizational structure.
Feasibility Study Steps
Define the problem and project scope.
Study the existing system.
Identify alternative solutions.
Estimate cost, benefits, risks and resources.
Evaluate each feasibility dimension.
Recommend the most suitable alternative.
Prepare the feasibility report.
Output: The feasibility report usually contains project objectives, alternatives,
cost-benefit analysis, risks, resource needs and a go/no-go recommendation.
3. Software Requirements Specification 14 Marks
SRS is a formal document that completely describes the functional and non-functional requirements of a software system.
Typical SRS Structure
Introduction and purpose
Scope of the system
Definitions and references
Overall description
Functional requirements
External interface requirements
Performance requirements
Security and safety requirements
Design constraints
Quality attributes
Acceptance criteria
Characteristics of a Good SRS
Correct
Complete
Unambiguous
Consistent
Verifiable
Modifiable
Traceable
Prioritized
Understandable
Advantages
Acts as an agreement between customer and developer.
Supports design, coding and testing.
Reduces misunderstandings.
Helps estimate effort and cost.
Provides a basis for acceptance testing.
4. Informal and Formal Specifications 14 Marks
Informal Specification
An informal specification describes requirements using natural language, diagrams, tables and examples.
Advantages
Easy for customers to understand.
Quick and inexpensive to prepare.
Suitable for communication and early discussion.
Limitations
May be ambiguous.
May contain inconsistency and incompleteness.
Difficult to verify mathematically.
Formal Specification
A formal specification uses mathematical notation, logic and precisely defined rules to describe system behavior and properties.
Advantages
Precise and unambiguous.
Supports proof and verification.
Detects inconsistency early.
Useful for critical systems.
Limitations
Requires mathematical expertise.
Expensive for ordinary projects.
Difficult for non-technical customers to understand.
Basis
Informal Specification
Formal Specification
Language
Natural language and diagrams
Mathematical notation
Ambiguity
Possible
Very low
Verification
Manual review
Formal proof possible
Understandability
High for customers
Requires trained readers
Use
General applications
Safety and mission-critical systems
5. Preconditions and Postconditions 7 Marks
A precondition is a condition that must be true before an operation starts. A postcondition is a condition that must be true after the operation finishes successfully.
Operation: withdraw(amount) Precondition: amount > 0 and balance ≥ amount Postcondition: new balance = old balance − amount
Benefits
Defines expected behavior precisely.
Clarifies responsibilities of caller and operation.
Supports testing and verification.
Helps detect invalid states.
Improves interface documentation.
6. Algebraic Specification 14 Marks
Algebraic specification describes an abstract data type by defining its operations and equations that specify the relationships among those operations.
Main Elements
Sorts: Types of data objects.
Operations: Functions that create or manipulate objects.
Axioms: Equations that define operation behavior.
Stack specification:
Sort: Stack, Element
Operations: create, push, pop, top, isEmpty
Axioms:
isEmpty(create) = true
isEmpty(push(S, x)) = false
top(push(S, x)) = x
pop(push(S, x)) = S
Advantages
Precise and implementation independent.
Suitable for abstract data types.
Supports consistency checking.
Can be used for formal verification.
Limitations
Difficult for state-oriented systems.
Requires mathematical understanding.
Large specifications may become complex.
7. Requirement Analysis Models 14 Marks
Requirement analysis models represent system data, functions, behavior and interactions in a structured visual or textual form.
Major Analysis Models
Scenario-based model: Use cases and user stories describe user-system interaction.
Data model: ER diagrams describe entities, attributes and relationships.
Flow-oriented model: DFD shows movement and transformation of data.
Class-based model: Classes, attributes, operations and relationships.
Behavioral model: State diagrams and sequence diagrams show dynamic behavior.
Requirements
|
+--> Scenario Model
|
+--> Data Model
|
+--> Flow Model
|
+--> Class Model
|
+--> Behavioral Model
Benefits
Improves understanding of complex requirements.
Detects missing and conflicting requirements.
Provides input for design.
Supports communication with stakeholders.
Creates traceability between requirements and design.
8. Specification and Design Tools 7 Marks
Data Flow Diagrams
Entity Relationship Diagrams
Data Dictionary
Decision Tables
Decision Trees
Structured English
Use Case Diagrams
Class Diagrams
Sequence Diagrams
State Transition Diagrams
Prototypes and wireframes
CASE tools
Selection of a tool depends on whether the analyst needs to model data, process flow,
decision logic, system behavior, object structure or user interaction.
9. Software Design 14 Marks
Software design is the process of transforming requirements into an architectural and detailed plan for implementing the software system.
Design Activities
Architectural design
Data design
Interface design
Component-level design
Deployment design
Requirements Model
|
v
Architectural Design
|
+--> Data Design
+--> Interface Design
+--> Component Design
|
v
Implementation Model
Design Output
Architecture diagrams
Database schema
Module specifications
Interface descriptions
Algorithms and pseudocode
Class and sequence diagrams
10. Software Design Objectives 7 Marks
Correctly satisfy requirements.
Reduce complexity.
Improve maintainability.
Support reuse.
Achieve high performance.
Improve reliability and security.
Make testing easier.
Support future changes.
Produce understandable documentation.
Characteristics of Good Design
Simple
Modular
Consistent
Efficient
Traceable
Reusable
Testable
Flexible
11. Software Design Principles and Techniques 14 Marks
Abstraction: Focus on essential features and hide unnecessary details.
Information hiding: Hide internal implementation behind interfaces.
Modularity: Divide the system into manageable components.
Separation of concerns: Keep different responsibilities separate.
Stepwise refinement: Move from high-level design to detail gradually.
Functional independence: Create modules with high cohesion and low coupling.
Reuse: Use existing components and patterns.
Consistency: Follow uniform conventions.
Design for change: Isolate areas likely to change.
Design for testability: Make components observable and controllable.
12. User Interface Design 14 Marks
User interface design defines how users interact with software through screens, controls, navigation, messages and feedback.
UI Design Principles
User familiarity
Consistency
Minimum surprise
Recoverability
User guidance
Accessibility
Clear feedback
Error prevention
Simple navigation
Responsive design
UI Design Process
Study users, tasks and environment.
Identify interface requirements.
Create navigation and information architecture.
Prepare sketches, wireframes and prototypes.
Define visual and interaction standards.
Evaluate through usability testing.
Refine the interface.
Common UI Errors
Inconsistent controls
Too much information on one screen
Poor color contrast
Unclear navigation
Technical error messages
No confirmation for destructive actions
13. Modularity 14 Marks
Modularity is the division of a software system into separate, manageable and logically independent modules.
Benefits
Reduces complexity.
Supports parallel development.
Simplifies testing and debugging.
Improves maintenance.
Supports reuse.
Limits the effect of changes.
Improves understandability.
Module Characteristics
Clear responsibility
Well-defined interface
Limited dependency
Information hiding
High internal relatedness
Complete System
|
+--> Module A
|
+--> Module B
|
+--> Module C
|
+--> Submodule C1
+--> Submodule C2
14. Cohesion and Coupling 14 Marks
Cohesion
Cohesion measures how strongly the elements inside a module are related. High cohesion is desirable.
From weakest to strongest:
Coincidental cohesion
Logical cohesion
Temporal cohesion
Procedural cohesion
Communicational cohesion
Sequential cohesion
Functional cohesion
Coupling
Coupling measures the dependency between modules. Low coupling is desirable.
From strongest to weakest:
Content coupling
Common coupling
External coupling
Control coupling
Stamp coupling
Data coupling
Message coupling
A good software design has high cohesion within modules and
low coupling between modules.
15. Functional Decomposition 7 Marks
Functional decomposition divides a complex system function into smaller sub-functions until each function is simple enough to design and implement.
Online Shopping System
|
+-----+------+-------------+
| | |
User Mgmt Product Mgmt Order Mgmt
|
+----+----+
| |
Payment Delivery
Advantages
Reduces complexity.
Clarifies responsibilities.
Supports top-down design.
Helps assign development tasks.
Improves testing and documentation.
16. Data Flow Diagram 14 Marks
A Data Flow Diagram is a graphical model that shows how data enters a system, is processed, stored and transferred to external entities.
DFD Symbols
Symbol
Meaning
Example
Rectangle
External entity
Customer
Circle / Rounded process
Process
Validate Order
Arrow
Data flow
Order Details
Open rectangle / parallel lines
Data store
Order Database
Levels of DFD
Context Diagram: Entire system shown as one process.
Level 0 DFD: Main system processes and stores.
Level 1 DFD: Detailed decomposition of a Level 0 process.
Lower levels: Additional detail when required.
Order
Customer --------------------> (1.0 Process Order)
^ |
| v
| Confirmation || Order File ||
| |
+----------------------------------+
DFD Rules
Every process should have at least one input and one output.
Data cannot move directly from one external entity to another.
Data cannot move directly from one data store to another.
Data cannot move directly between external entity and data store.
Parent and child DFDs should be balanced.
Use meaningful process and data-flow names.
17. Data Dictionary 14 Marks
A data dictionary is a centralized collection of definitions describing data elements, data structures, data flows and data stores used in a system.