************ [WIEGERS-2003], Chapter 1 **************************************************************
Many software proble...
Requirements management entails
"establishing and maintaining an
agreement with the customer on the
requirements for the s...
************ [WIEGERS-2003], Chapter 2 **************************************************************
Customer is an indiv...
************ [WIEGERS-2003], Chapter 3 **************************************************************
A Requirements Development Process
************ [WIEGERS-2003], Chapter 5 ************************************************...
Business Requirements and Use Cases
The business requirements determine both the set of business tasks (use cases) that th...
Reading Summary - Software Requirements + Characteristics of Well Written Requirements
Upcoming SlideShare
Loading in …5
×

Reading Summary - Software Requirements + Characteristics of Well Written Requirements

392 views
268 views

Published on

[WIEGERS-2003], Chapter 1
[WIEGERS-2003], Chapter 2
[WIEGERS-2003], Chapter 3
[WIEGERS-2003], Chapter 5

Published in: Technology
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
392
On SlideShare
0
From Embeds
0
Number of Embeds
16
Actions
Shares
0
Downloads
9
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

Reading Summary - Software Requirements + Characteristics of Well Written Requirements

  1. 1. ************ [WIEGERS-2003], Chapter 1 ************************************************************** Many software problems arise from shortcomings in the ways that people gather, document, agree on, and modify the product's requirements. The problem areas might include informal information gathering, implied functionality, erroneous or uncommunicated assumptions, inadequately defined requirements, and a casual change process. Requirements are a specification of what should be implemented. They are descriptions of how the system should behave, or of a system property or attribute. They may be a constraint on the development process of the system (Sommerville 1997). Requirements must be documented, they are the foundation for both the software development and the project management activities, all stakeholders must be committed to following an effective requirements process. Software requirements include three distinct levels—business requirements, user requirements, and functional requirements. In addition, every system has an assortment of nonfunctional requirements. Business requirements describe why the organization is implementing the system— the objectives the organization hopes to achieve. User requirements describe user goals or tasks that the users must be able to perform with the product. Functional requirements specify the software functionality that the developers must build into the product to enable users to accomplish their tasks, thereby satisfying the business requirements. Functional requirements are documented in a software requirements specification (SRS). System requirements describes the top- level requirements for a product that contains multiple subsystems—that is, a system. A feature is a set of logically related functional requirements that provides a capability to the user and enables the satisfaction of a business objective. Requirements specifications do NOT include design or implementation details (other than known constraints), project planning information, or testing information. These are project requirements but not product requirements; These sub disciplines encompass all the activities involved with gathering, evaluating, and documenting the requirements for a software or software-containing product.
  2. 2. Requirements management entails "establishing and maintaining an agreement with the customer on the requirements for the software project". It costs far more to correct a defect that's found late in the project than to fix it shortly after its creation. Preventing requirements errors and catching them early therefore has a huge leveraging effect on reducing rework. When Bad Requirements Happen to Nice People  Insufficient user involvement leads to late-breaking requirements that delay project completion.  Creeping User Requirements  Ambiguous Requirements  Gold Platting, when a developer adds functionality that wasn't in the requirements specification  Minimal Specification  Overlooked User Classes  Inaccurate Planning Benefits from a High-Quality Requirements Process  Fewer requirements defects  Reduced development rework  Fewer unnecessary features  Lower enhancement costs  Faster development  Fewer miscommunications  Reduced scope creep  Reduced project chaos  More accurate system-testing estimates  Higher customer and team member satisfaction Requirement Statement Characteristics  Complete  Correct  Feasible  Necessary  Prioritized  Unambiguous  Verifiable Requirements Specification Characteristics  Complete  Consistence  Modifiable  Traceable
  3. 3. ************ [WIEGERS-2003], Chapter 2 ************************************************************** Customer is an individual or organization who derives either direct or indirect benefit from a product. Signing off on the requirements document is the mark of customer approval of the requirements. Don't use sign-off as a weapon. Use it as a project milestone, with a clear, shared understanding of the activities that lead to sign-off and its implications for future changes
  4. 4. ************ [WIEGERS-2003], Chapter 3 **************************************************************
  5. 5. A Requirements Development Process ************ [WIEGERS-2003], Chapter 5 ************************************************************** Establishing the Product Vision and Project Scope The business requirements represent the top level of abstraction in the requirements chain: they define the vision and scope for the software system. The user requirements and software functional requirements must align with the context and objectives that the business requirements establish. Requirements that don't help the project achieve its business objectives shouldn't be included. Defining the Vision through Business Requirements
  6. 6. Business Requirements and Use Cases The business requirements determine both the set of business tasks (use cases) that the application enables (the application breadth) and the depth or level to which each use case is implemented. If the business requirements help you determine that a particular use case is outside the project's scope, you're making a breadth decision. The depth of support can range from a trivial implementation to full automation with many usability aids. The business requirements will imply which use cases demand robust, comprehensive functional implementation and which require merely superficial implementation, at least initially. Vision and scope document collects the business requirements into a single document that sets the stage for the subsequent development work. Business Opportunity: Exploit the poor security record of a competing product. Business Objective: Capture a market share of 80 percent by being recognized as the most secure product in the market through trade journal reviews and consumer surveys. Customer Need: A more secure product. Feature: A new, robust security engine. The scope description establishes the boundary and connections between the system we are developing and everything else in the universe. The context diagram graphically illustrates this boundary. It identifies terminators outside the system that interface to it in some way, as well as data, control, and material flows between the terminators and the system. The purpose of tools such as the context diagram is to foster clear and accurate communication among the project stakeholders.

×