Reading Summary - Software Requirements + Characteristics of Well Written Requirements

50 %
50 %
Information about Reading Summary - Software Requirements + Characteristics of Well...

Published on March 13, 2014

Author: ArtemisaYescasEngler



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

************ [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.

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

************ [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

************ [WIEGERS-2003], Chapter 3 **************************************************************

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

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.

Add a comment

Related presentations

Related pages

Writing Good Requirements – The Big Ten Rules | Tyner Blain

... they provide a list of 8 characteristics of good requirements ... to be written. Everyone reading this ... A well written requirement is ...
Read more

Writing Quality Requirements - Process Impact -- Software ...

This article describes several characteristics of high quality software ... poorly written requirement is a ... Writing Quality Requirements.
Read more

Requirement - Wikipedia, the free encyclopedia

... should be written as two separate requirements ... characteristic of requirements has led to ... describing software requirements ...
Read more

Karl Wiegers Describes 10 Requirements Traps to Avoid

Karl Wiegers Describes 10 Requirements Traps to Avoid. ... of Software Requirements . ... implement portions of the requirements as they become well ...
Read more

Business Requirements Guidelines - WriteBIZness, LLC

... without prior written ... Characteristics of Well-Defined Requirements ... Business Requirements Guidelines A Summary of the Process
Read more

The Seven Characteristics Of Highly Successful Projects

The Seven Characteristics Of Highly Successful Projects 1 ... Clear requirements, well managed ... as well as the use of existing software in new, ...
Read more

How to write a software requirements specification ...

How to write a software requirements specification by Robert Japenga . What Makes a Great Software Requirements Specification? There are many good ...
Read more

Writing reports - University of Leicester — A Leading UK ...

This guide has been written to provide a general introduction to writing reports. ... A well written report will demonstrate your ability ... Summary ...
Read more

Technical writing specification - Wikiversity

Technical writing specification. ... A collection of requirements define the characteristics or features ... Well-written requirement specifications ...
Read more

IEEE Software Requirements Specification Template

Title: IEEE Software Requirements Specification Template Author: Doris Sturzenberger Last modified by: Support Created Date: 1/30/2007 2:57:00 PM Other titles
Read more