Software Requirements Engineering Best Practices Beyond Development
Gain insights into translating requirements into a plan and design before programming, estimating requirements effort, project size and schedule implications, architecture considerations, and the importance of aligning design with requirements for optimal software development outcomes. Dive into practical approaches and key strategies to streamline the software requirements engineering process efficiently.
Download Presentation
Please find below an Image/Link to download the presentation.
The content on the website is provided AS IS for your information and personal use only. It may not be sold, licensed, or shared on other websites without obtaining consent from the author. If you encounter any issues during the download, it is possible that the publisher has removed the file from their server.
You are allowed to download the files provided on this website for personal or commercial use, subject to the condition that they are used lawfully. All files are the property of their respective owners.
The content on the website is provided AS IS for your information and personal use only. It may not be sold, licensed, or shared on other websites without obtaining consent from the author.
E N D
Presentation Transcript
Chapter 19 Beyond requirements development EECS812: Software Requirements Engineering Professor Hossein Saiedian
This chapter will help you to Understand the value of translating requirements into a plan and design before any programming begins Learn some common approaches to get from requirements to release See how requirements influence all other aspects of the project EECS812: Software Requirements Engineering 2
Estimating requirements effort Must be scheduled up front as a part of project plan Studies: ~15% of total effort, ~40% of total scheduled time Predictability: fewer cost and schedule overruns with greater requirements effort More time on requirements = less time in development EECS812: Software Requirements Engineering 3
Requirements > project size Thorough requirements greatly aid time and effort estimation Project size can be based on: Number of individual requirements Function points Use case points or story points (agile) Number, type, complexity of user interface elements Estimated LOC Experience is key EECS812: Software Requirements Engineering 4
Requirements > project schedule Avoid right-to-left scheduling Project schedule can be based on: Project size Historical productivity of development team Total tasks to complete Stability of requirements Experience is still key EECS812: Software Requirements Engineering 5
Requirements > architecture Driven by functional and quality requirements, but also constraints Prototyping can aid this decision Does this architecture I m considering enable me to fulfill ALL requirements? Analysis can also expose holes in requirements EECS812: Software Requirements Engineering 6
Requirements > design Compare design to requirements to: Solidify architecture choice Determine common object classes and existing, reusable elements Ensure design satisfies all requirements And doesn t introduce bloat Map design elements to requirements Extract exception conditions Ensure quality goals are met Get a greater understanding of the constraints imposed by requirements and architecture EECS812: Software Requirements Engineering 7
Requirements > testing Tests maps back to requirements: Expected behavior under certain conditions Error conditions and how to handle them Quality expectations satisfaction Other than testing: Code inspection Demonstration Analysis EECS812: Software Requirements Engineering 8
Summary Requirements feed all other project tasks More requirements makes for a more predictable project, good business value Going through the other project tasks that look back at requirements can expose holes and shortcomings Consider SRS a living document EECS812: Software Requirements Engineering 9
