SRE UNIT 5 BUILDING THE RIGHT SYSTEM.docx

UNIT 5 BUILDING THE RIGHT SYSTEM
FROM USE CASE TO IMPLEMENTATION:
Use cases are a valuable tool in the software development process as they help define
the functional requirements of a system from the user's perspective. Here's a high-level
overview of how you can go from a use case to implementation:
1. Use Case Identification:
 Identify and define the use cases for your software. Use cases describe specific
interactions between users (actors) and the system to achieve a particular goal or
functionality.
2. Requirements Analysis:
 Analyze the use cases to extract detailed functional and non-functional
requirements. These requirements should include what the system needs to do
and any constraints or quality attributes it must meet.
3. Design:
 Create a high-level design for your software based on the requirements gathered
from the use cases. This includes architectural decisions, such as choosing the
appropriate technologies and frameworks.
4. Use Case Modeling:
 Refine the use cases into detailed models, such as UML diagrams (use case
diagrams, sequence diagrams, activity diagrams, etc.). These models provide a
visual representation of how the system and users interact.
5. Software Architecture:
 Develop the software architecture that aligns with the use cases. Identify the
major components, modules, and their relationships. Ensure that the architecture
can accommodate the functionality described in the use cases.
6. Implementation Planning:
 Plan the implementation phase, including task allocation, timelines, and resource
allocation. Create a development roadmap that outlines how each use case will
be implemented.
7. Coding:
 Begin writing the actual code for the software. Developers translate the use case
descriptions and system design into functional software components.
8. Testing:
 Conduct testing activities, including unit testing, integration testing, and system
testing, to ensure that the implemented code fulfills the requirements outlined in
the use cases.
9. Iteration:

 Use feedback from testing to refine the code and address any issues or bugs. This
may involve revisiting the design and making adjustments based on the testing
results.
10. Documentation:
 Create documentation that includes user manuals, developer guides, and system
documentation. This helps users and future developers understand the software's
functionality and how it aligns with the original use cases.
11. Deployment:
 Deploy the software to the target environment, whether it's on-premises servers,
cloud infrastructure, or mobile devices. Ensure that the deployment process
aligns with the use cases and requirements.
12. Maintenance and Updates:
 After deployment, continue to maintain and update the software as needed. This
may involve adding new features, fixing bugs, and ensuring that the software
remains aligned with evolving use cases.
13. User Training:
 Provide training to end-users to ensure they can effectively use the software
based on the documented use cases.
14. Monitoring and Feedback:
 Implement monitoring tools and collect feedback from users to identify any
issues or areas for improvement. Use this feedback to inform future updates and
enhancements.
The transition from use cases to implementation is an iterative process, and it's crucial to
maintain clear communication between stakeholders, including developers, testers, and
end-users, to ensure that the final software product meets the intended goals and
requirements as defined in the use cases.
FROM USE CASES TO TEST CASES:
Test cases are designed to verify that the software functions correctly and meets the
requirements outlined in the use cases. Here's how you can go from defining use cases
to creating test cases:
1. Understand the Use Cases:
 Start by thoroughly understanding the use cases that have been defined. Use
cases describe the interactions between users and the system, specifying the
expected behavior and outcomes.
2. Identify Testable Scenarios:

 From each use case, identify the specific scenarios or paths that need to be
tested. These scenarios should cover both typical and exceptional user
interactions.
3. Define Test Objectives:
 Clearly define the objectives of each test scenario. What are you trying to verify
or validate with each test case? This could include checking the system's
response, data validation, or error handling.
4. Create Test Cases:
 For each identified scenario, create test cases that outline the step-by-step
instructions for testing that scenario. Each test case should include the following
elements:
 Test Case ID: A unique identifier for the test case.
 Test Description: A brief description of what the test case is checking.
 Preconditions: Any necessary conditions or setup required before running
the test.
 Test Steps: Detailed instructions on how to execute the test, including
user actions and expected results.
 Expected Results: The expected outcome or behavior of the system.
 Postconditions: Any state or cleanup required after running the test.
5. Consider Variations and Edge Cases:
 Think about variations of the scenarios, different inputs, and edge cases that
might affect the system's behavior. Create additional test cases to cover these
situations.
6. Prioritize Test Cases:
 Prioritize test cases based on factors like criticality, frequency of use, and risk. This
helps in focusing testing efforts on the most important aspects of the system.
7. Review and Validation:
 Review the test cases with relevant stakeholders, including developers and
business analysts, to ensure they accurately reflect the use cases and their
requirements.
8. Test Data Preparation:
 Ensure that you have the necessary test data and environment set up to execute
the test cases. This might involve creating sample data or configuring test
systems.
9. Execute Test Cases:
 Execute the test cases as part of the software testing process. Record the actual
results and compare them with the expected results.
10. Defect Reporting:

 If any discrepancies or defects are identified during testing, document them in a
defect tracking system. Include details such as steps to reproduce the issue and
its severity.
11. Regression Testing:
 After defects are fixed, perform regression testing to ensure that the changes do
not introduce new issues and that the system still meets the requirements of the
use cases.
12. Iterate and Repeat:
 Continue this process iteratively throughout the development lifecycle, especially
during development sprints or cycles. Test cases may evolve as the software
evolves.
13. Test Automation:
 Consider automating repetitive and critical test cases to streamline the testing
process and ensure consistency in testing across different releases.
14. Documentation:
 Maintain comprehensive documentation of all test cases, including updates as
the software changes and evolves.
The transition from use cases to test cases is crucial for ensuring that the software meets
user expectations and functions correctly. It also helps in verifying that the software
conforms to the requirements and use cases defined earlier in the development process.
Effective test case design and execution contribute to the overall quality and reliability
of the software product.
TRACING REQUIREMENTS:
Tracing requirements in software engineering is the process of establishing and
maintaining links between various artifacts and documents throughout the software
development lifecycle to ensure that the final product aligns with the original
requirements. This helps in maintaining transparency, traceability, and accountability in
the development process. Here are the key steps involved in tracing requirements in
software engineering:
1. Requirement Elicitation:
 The process begins with the identification and gathering of requirements from
stakeholders. These requirements can take various forms, such as functional
requirements, non-functional requirements, business rules, and user stories.
2. Requirement Documentation:

 Once requirements are collected, they should be documented in a clear and
standardized format. Common methods for documenting requirements include
use cases, user stories, requirement specification documents, and formal
modeling languages like UML.
3. Requirements Management Tool:
 Use a requirements management tool or software to store and organize the
documented requirements. These tools facilitate version control, collaboration,
and traceability.
4. Requirement Tracing Matrix:
 Create a traceability matrix that establishes links between requirements and other
artifacts. This matrix typically includes columns for requirements, design
elements, test cases, and defects. Each requirement is linked to the
corresponding elements in these columns.
5. Design Phase:
 During the design phase, design documents, architectural diagrams, and other
design artifacts are created. Establish links between design elements and the
corresponding requirements in the traceability matrix. Ensure that the design
elements address the requirements adequately.
6. Development Phase:
 As developers write code, they should reference the requirements that are being
implemented. Use code comments or references in the codebase to link specific
code segments to the requirements they fulfill.
7. Testing Phase:
 Develop test cases based on the requirements. Create a mapping between test
cases and requirements in the traceability matrix. This ensures that each
requirement is tested and validated.
8. Traceability Validation:
 Regularly review and validate the traceability matrix to ensure that links between
artifacts are accurate and up to date. If requirements change, update the matrix
accordingly.
9. Change Management:
 When a requirement changes or evolves, update the traceability matrix, and
ensure that the changes are reflected in the design, code, and test cases. This
helps in managing the impact of requirement changes on the entire development
process.
10. Defect Tracking:
 When defects are identified during testing or post-release, link them back to the
specific requirements they impact. This helps in understanding the root cause
and facilitates resolution.
11. Audit and Compliance:

 Tracing requirements is often necessary for regulatory compliance and audits.
Having a well-maintained traceability matrix provides evidence that the software
has been developed in accordance with specified requirements.
12. Documentation and Reporting:
 Maintain comprehensive documentation of the tracing process and generate
reports that show the status of traceability. These reports help in tracking
progress and identifying any gaps or discrepancies.
13. Continuous Improvement:
 Continuously improve the traceability process by incorporating feedback and
lessons learned from previous projects. Ensure that the process remains efficient
and effective.
The forward trace: This is the process of verifying that requirements
correspond to system components, design elements and other
deliverables.
The backward trace: This is the process of verifying why certain
features were included to create an audit trail for later reference.
Tracing requirements throughout the software development lifecycle is crucial for
ensuring that the final product meets stakeholder expectations, maintains alignment
with business goals, and facilitates effective communication among development teams
and stakeholders. It also aids in risk management and change control, ultimately
contributing to the overall success of the software project.
MANAGING CHANGE:
Change Management in software development refers to the transition from an
existing state of the software product to another improved state of the product.
It controls, supports, and manages changes to artifacts, such as code changes,
process changes, or documentation changes. Where CCP (Change Control
Process) mainly identifies, documents, and authorizes changes to a software
application.
Each software development process follows Software Development Life Cycle
(SDLC) where each phase is accordingly followed to finally deliver a good
quality software product. Change Management does not come under any
phases of SDLC still it has great importance in the entire software development
process. There are various types of change management tools that are used for
various purposes like to adopt, control, represent and effect the change

required. For example Change management tools for Flow Charting, Project
Planning, Data collection, etc.
Process of Change Management :
When any software application/product goes for any changes in an IT
environment, it undergoes a series of sequential processes as follows:
 Creating a request for change
 Reviewing and assessing a request for change
 Planning the change
 Testing the change
 Creating a change proposal
 Implementing changes
 Reviewing change performance
 Closing the process
IMPORTANCE:
 For improving performance
 For increasing engagement
 For enhancing innovation
 For including new technologies
 For implementing new requirements
 For reducing cost
Source of Change :
There may be multiple reasons involved during the development process for
which certain changes are required to be implemented in the product. These
sources are as follows :

 Business reorganization
 New Market conditions
 New equipment
 Fixing any bugs/errors
 New customer needs
 Performance or reliability improvement
 Budgetary or scheduling constraints
Key points to be considered during Change Management :
 Reason of change
 Result of change
 The portion to be changed
 Person will change
 Risks involved in change
 Alternative to change
 Resources required for change
 Relationship between changes
ASSESSING REQUIREMENTS QUALITY IN ITERATIVE DEVELOPMENT:
Assessing requirements quality in iterative development in software engineering is
crucial to ensure that the software product meets its intended goals and that changes or
refinements are managed effectively throughout the development process. Here are
some key practices and techniques to assess requirements quality in an iterative
development environment:
1. Clear and Understandable Requirements:
 Ensure that the requirements are clear, concise, and easily understandable by all
stakeholders, including developers, testers, and end-users. Ambiguities or vague
language should be addressed promptly.
2. Use Acceptance Criteria:
 Define acceptance criteria for each requirement. These criteria provide specific,
measurable conditions that must be met for a requirement to be considered
complete. They serve as a basis for validation.
3. Prioritize Requirements:
 Prioritize requirements based on their importance and business value. Use
techniques like MoSCoW (Must have, Should have, Could have, Won't have) to
categorize requirements.
4. Requirements Traceability:

 Establish traceability between requirements and other project artifacts, such as
design, code, test cases, and user stories. This helps in tracking the impact of
changes and ensures that all requirements are addressed.
5. Validation with Stakeholders:
 Regularly review requirements with stakeholders, including product owners,
users, and business analysts. Gather feedback and ensure that the requirements
align with the evolving needs of the project.
6. Prototyping and Mockups:
 Create prototypes or mockups of user interfaces or system behavior to help
stakeholders visualize and validate requirements early in the process.
7. Use of User Stories:
 In Agile and iterative development, user stories are often used to capture
requirements. Ensure that user stories follow the INVEST (Independent,
Negotiable, Valuable, Estimable, Small, Testable) principles.
8. Incremental Development:
 Break down requirements into smaller, manageable pieces and develop them
incrementally. This allows for faster feedback and ensures that changes can be
incorporated more easily.
9. Validation through Testing:
 Develop test cases based on requirements and use them to validate whether the
software meets the specified requirements. Automated testing can aid in
regression testing as requirements change.
10. Continuous Integration and Continuous Delivery (CI/CD):
 Implement CI/CD pipelines to automatically build, test, and deploy software. This
ensures that changes to requirements are quickly integrated and tested.
11. Requirement Change Management:
 Establish a robust change management process to handle requirement changes.
Ensure that changes are well-documented, reviewed, and approved by relevant
stakeholders.
12. Risk Assessment:
 Identify potential risks associated with each requirement. Assess how changes to
a requirement may impact project scope, timeline, and resources.
13. Metrics and Quality Gates:
 Define quality metrics and quality gates that requirements must meet before
moving on to the next development iteration. This ensures that only high-quality
requirements are implemented.
14. Documentation and Version Control:

 Maintain comprehensive documentation of requirements and use version control
systems to track changes. This helps in understanding the evolution of
requirements over time.
15. Retrospectives:
 Conduct regular retrospectives to reflect on the quality of requirements and the
effectiveness of the development process. Use feedback to make continuous
improvements.
16. Continuous Learning:
 Encourage a culture of continuous learning and improvement within the
development team. Share knowledge and best practices to enhance requirements
quality.
Assessing requirements quality in an iterative development environment is an ongoing
process. By incorporating these practices and adapting to the changing needs of the
project, you can ensure that your software development efforts are aligned with
stakeholder expectations and deliver a high-quality product.
AGILE REQUIREMENT METHODS:
Agile software development emphasizes collaboration, flexibility, and customer-
centricity. Agile requirements methods are approaches to gathering, documenting, and

managing requirements that align with the Agile principles and practices. Here are some
commonly used Agile requirement methods:
1. User Stories:
 User stories are concise, user-focused descriptions of functionality written from
the user's perspective. They follow a simple template: "As a [user role], I want [an
action] so that [benefit/value]." User stories are often written on index cards or
digitally and are used as the basis for development tasks.
2. Product Backlog:
 The product backlog is a prioritized list of user stories and requirements that
need to be implemented in the product. It's maintained by the product owner
and can change frequently as new insights emerge.
3. Story Mapping:
 Story mapping is a visualization technique used to organize and prioritize user
stories. It involves creating a visual map of user stories, arranging them into
vertical columns representing different releases or sprints, and breaking them
down into smaller tasks.
4. Acceptance Criteria:
 Each user story should have associated acceptance criteria that define the
conditions under which the story is considered "done." These criteria help in
determining when a feature is complete and meet the required quality standards.
5. Definition of Ready (DoR) and Definition of Done (DoD):
 These are checklist-like sets of criteria that help ensure that user stories are ready
for development (DoR) and that they are complete and meet quality standards
(DoD). These definitions are agreed upon by the team.
6. Sprint Planning:
 Agile teams use sprint planning meetings to select a set of user stories from the
product backlog to work on during the upcoming sprint. This process involves
estimating the effort required for each story and considering team capacity.
7. Daily Standup Meetings (Daily Scrum):
 Daily standup meetings are short, daily gatherings where team members discuss
what they've accomplished, what they plan to do next, and any blockers they're
facing. These meetings help ensure that everyone is aligned and focused on the
sprint goals.
8. Sprint Review:
 At the end of each sprint, the team holds a sprint review meeting to demonstrate
the completed work to stakeholders and gather feedback. This is an opportunity
to validate that the product increment aligns with user needs.
9. Sprint Retrospective:

 The sprint retrospective is a meeting held at the end of each sprint to reflect on
what went well, what could be improved, and what actions can be taken to
enhance the team's effectiveness. This includes improving the requirements
process.
10. Customer Feedback and Collaboration:
 Agile encourages ongoing collaboration with customers and stakeholders.
Feedback is gathered throughout the development process, and requirements
may evolve based on this feedback.
11. Prototyping and Wireframing:
 Agile teams may use prototypes, wireframes, or mockups to visualize and validate
requirements before development. These artifacts help ensure a shared
understanding of the desired functionality.
12. Behavior-Driven Development (BDD):
 BDD is a practice that involves writing test scenarios in plain language (e.g.,
Given-When-Then format) to describe the expected behavior of a feature. These
scenarios serve as both requirements and automated test cases.
13. Continuous Integration and Continuous Delivery (CI/CD):
 Agile teams often use CI/CD pipelines to automate building, testing, and
deploying software, ensuring that requirements are implemented correctly and
quickly delivered to users.
14. A/B Testing and Feature Flags:
 Agile teams may use A/B testing and feature flags to gradually roll out new
features to users, gather feedback, and make adjustments based on user behavior
and preferences.
15. Customer Journey Mapping:
 Customer journey mapping is a technique to understand how users interact with
a product. It helps in identifying user pain points and opportunities for
improvement in the product.

These Agile requirement methods promote flexibility, collaboration, and a focus on
delivering value to customers. Agile teams adapt these methods to fit their specific
needs and project contexts, allowing them to respond to changing requirements and
deliver software that meets customer expectations

SRE UNIT 5 BUILDING THE RIGHT SYSTEM.docx

More Related Content

Similar to SRE UNIT 5 BUILDING THE RIGHT SYSTEM.docx (20)

Recently uploaded (20)

SRE UNIT 5 BUILDING THE RIGHT SYSTEM.docx