Similar presentations:
Software requirements (lecture 5)
1.
Software architecture2024-2025
Gulnur Smagulova,
Major: Software Engineering
Zhuldyz Basheyeva,
Term: 2 , third year
Olzhas Aitmukhambetov
Credits: 5
2.
Software RequirementsLecture 3
3.
Agenda1. Fundamentals (Stakeholder Requirements)
2. Product and Process
3. Requirements
4. Specifications
4.
Fundamentals:Stakeholder
Requirements
Stakeholder requirements serve as the
foundation for software development by
capturing the expectations and needs of
everyone involved.
5.
Key Concepts:- Stakeholders: Individuals or groups impacted by or involved in the
system, including clients, developers, users, and managers.
- Purpose: To ensure clarity and agreement on the desired outcomes
before development begins.
- Techniques: Methods such as interviews, surveys, and observation are
used to extract stakeholder needs.
Benefits:
- Aligning the development process with business goals.
- Minimizing misunderstandings between developers and clients.
6.
Product andProcess
Requirements
Software requirements are classified into two major
types:
1.Product Requirements
2.Process Requirements
7.
Product RequirementsDefine what the system should do.
- Functional requirements specify specific behaviors or functions.
- Non-functional requirements focus on system qualities like
performance, scalability, and usability.
Process Requirements
Relate to the methods and tools used during development.
- Define development constraints like timelines, technologies, or
standards.
Comparison:
- Product requirements affect the delivered system.
- Process requirements guide how the system is built.
8.
The Nature of Requirements:Requirements
- Explicit vs. Implicit: Explicit requirements are
documented clearly, while implicit requirements may
stem from stakeholder assumptions.
- Prioritization: Assigning importance levels to
requirements using methods such as MoSCoW (Must
have, Should have, Could have, Won't have).
9.
Common Pitfalls:- Ambiguity in documentation.
- Changes in scope mid-project.
Examples of Requirements Documentation:
- Use case diagrams (capturing functionality).
- Text-based requirement lists with unique IDs for traceability.
10.
SpecificationsPurpose: Transform raw requirements into clear,
actionable documentation for developers.
11.
Key Elements:- Requirement Specifications: Detailing each requirement with
examples, constraints, and intended functionality.
- System Models: Often using UML diagrams to visualize
system interactions (refer to component diagrams on textbook
pageY).
- Validation and Verification: Ensuring each specification aligns
with stakeholder needs and technical feasibility.
12.
Formats of Specifications:- Textual format (tables and detailed descriptions).
-
Visual representation (e.g., sequence diagrams).
Example:
A sequence diagram illustrating user login functionality.
Stakeholders can validate this as an accurate interpretation of
their needs.
13.
- Stakeholder requirements drive the successof software projects by aligning goals.
Conclusion
- Distinct classification between product and
process ensures holistic coverage of
constraints and capabilities.
- Well-documented
requirements
and
specifications
pave
the
way
for
maintainable, scalable, and robust systems.
software