Software Systems Requirements and Architecture SWEN440 Bob Kuehl - PowerPoint PPT Presentation

Software Systems Requirements and Architecture SWEN440 Bob Kuehl R. Kuehl/J. Scott Hawker p. 1 R I T Software Engineering

Your Experience?  ”The project's vision and scope are never clearly defined.  Customers are too busy to spend time working with analysts or developers on the requirements.  User surrogates, such as product managers, development managers, user managers, or marketers, claim to speak for the users, but they don't accurately represent user needs.  Requirements exist in the heads of "the experts" in your organization and are never written down.  Customers claim that all requirements are critical, so they don't prioritize them.  Developers encounter ambiguities and missing information when coding, so they have to guess.  Communications between developers and customers focus on user interface displays and not on what the users need to do with the software.  Your customers sign off on the requirements and then change them continuously.  The project scope increases when you accept requirements changes, but the schedule slips because no additional resources are provided and no functionality is removed.  Requested requirements changes get lost, and you and your customers don't know the status of all change requests.  Customers request certain functionality and developers build it, but no one ever uses it.  The specification is satisfied, but the customer is not.” Wiegers P. 5 R. Kuehl/J. Scott Hawker p. 2 R I T Software Engineering

Software Engineering Context Problem Domain This Course Requirements Rework >Value Architecture Projects fail if $Rework > $Value Work >$ Cost Design > Knowledge Implementation >Complexity <Risk Test and Deployment Time What methodology = f (experience, environment, size ) Product or Service R. Kuehl/J. Scott Hawker p. 3 R I T Software Engineering

Rational Unified Process R. Kuehl/J. Scott Hawker p. 4 R I T Software Engineering

Context  Software requirements are the single most important element of project success  Miss the requirements, the delivered project is wrong, no matter how technically magical  Requirements management drives project budget and schedule, which are common causes of project failure  Software architecture is the foundational design response to software requirements  Functional requirements  module decomposition, separation of concerns  Quality requirements  quality-specific design patterns and tactics R. Kuehl/J. Scott Hawker p. 5 R I T Software Engineering

Types of Requirements Business Requirements Business Rules Vision and Scope Document Quality Attributes User Requirements User Requirements Document External Interfaces System Functional Constraints Requirements Requirements Software Requirements Specification Solid arrow – stored in Dotted arrow – origin of or influence R. Kuehl/J. Scott Hawker p. 6 R I T Software Engineering

Types of Requirements  Business – business objectives, the “business case”  Business rules – policy, guideline, regulation, algorithm  User – goals and tasks for a class of user; HCI  Quality Attributes – non-functional level of service  System – high level requirements for the system at large  External Interface – interfaces to users and/or other systems  Constraints – development choice restrictions  Functional – behavior the system must exhibit to satisfy user and business requirements R. Kuehl/J. Scott Hawker p. 7 R I T Software Engineering

Software Architecture Design Reference Model Requirements: Architecture • Domain functions Design • Quality attributes Documentation • Use cases Architecture Module Architecturally Significant Drivers decomposition Requirements Subset design Quality Design Attribute decision Scenarios analysis Architecture Pattern and Pattern design tactics “Catalog” selection R. Kuehl/J. Scott Hawker p. 8 R I T Software Engineering

Big Picture Views  Product requirements and architecture are big- picture (holistic) views of the system  Strategic  Abstract  Drive later development  Detailed requirements and design elaborate initial requirements and architecture design  Details of technology choices and programming, integration, and test issues  There are multiple views of a single system  No one view can capture the scope and complexity of a useful system  Manage complexity, don’t avoid it R. Kuehl/J. Scott Hawker p. 9 R I T Software Engineering

Software Engineering Roles  Analyst – performs requirements engineering activities to specify and manage requirements  Architect – designs and documents a software architecture that satisfies system requirements R. Kuehl/J. Scott Hawker p. 10 R I T Software Engineering

Requirements and Architecture Project Application Domain Product Product Champion Champion Developer Stakeholder Developer Stakeholder (Team roles) (Team roles) Review Feedback Elicitation • Requirements Artifacts • Requirements Artifacts • Software Architecture Design • Software Architecture Design R. Kuehl/J. Scott Hawker p. 11 R I T Software Engineering