Wiegers-2006 Capitulo 8

Capitulo 3 Improving Your Requirements Reviews

What Can Better Requirements Do for You?  Educate the reviewers
 Selecting projects to fund  Don't overwhelm the reviewers
 Facilitating estimation  Build a collaborative partnership with the
 Enabling prioritization user representatives and other project
 Developing designs participants
 Testing effectively  Invite the right reviewers
The Investment  Have reviewers examine appropriate
 Assessing current practices deliverables
 Developing new processes and templates  Design for reviewability
 Training the team  Inspect all requirements deliverables
 Acquiring books and other resources  Emphasize finding major errors
 Employing external consultants Capitulo 15
 Buying requirements management tools Elements of Requirements Style
The Return  I Shall Call This a Requirement (shall, must,
An Economic Argument should, could, would).
Capitulo 4  System Perspective or User Perspective?
Project Type o Conditions: "When [some conditions are
 Management information systems true] …"
 Systems software o Result:"the system shall [do something]"
 Commercial products o Qualifier: "[response time goal or quality
 Military software objective]."
 Outsourced projects o User type: "The [user class or actor
name]"
Planning Elicitation
o Result type: "shall be able to [do
 Negotiating with product champions.
something] "
 Holding elicitation workshops and conducting
o Object: "[to something]."
interviews.
o Qualifier: [response time goal or quality
 Reviewing existing documents and products.
objective].
 Preparing, distributing, and analyzing surveys.
 Creating and evaluating prototypes, analysis
 Parent and Child Requirements (1
models, and other requirements views. Requerimiento… 1.1 Requerimiento mas
 Performing feasibility, risk, safety, failure, and
especifico)
hazard analyses.  Ambiguities and missing requirements
 Entering requirements into a database.
contienen:
 Reviewing requirements specifications. o Complex Logic
 Developing test cases from requirements and o Negative Requirements or inverse
walking through the test cases. o Omissions
 Revising requirements specifications following o Boundaries (sin limites)
review or test analysis. o Ambiguous Wording (Synonyms,
Capitulo 5 Estimating Based on Requirements Pronouns, The abbreviations, Adverbs)
Estimation Approaches Capitulo 16
 Bottom-up, Top-down, Cost models, Expert Solution Ideas and Design Constraints
opinión, Analogy Solution Clues
Goals Aren't Estimates Capitulo 18
Estimating from Requirements  Requirements Baseline
 Effort = Size ÷ Productivity  When to Baseline
Measuring Software Size o Formal change control begins
Story Points o Project managers determine the staffing
Use Case Points levels and budgets(presupuesto) needed
Testable Requirements o Project managers make Schedule
The Reality of Estimation o Factors to Consider Before Defining a
Requirements Baseline (ver hoja)
 o Listening skills
Capitulo 19 o Interviewing and questioning skills
Requirements o Analytical skills
Limitations of Natural Language o Facilitation skills
Some Alternative Requirements Views o Organizational skills
 Graphical Analysis Models o Modeling skills
 Decision Tables and Decision Trees o Interpersonal skills
 Test Cases o Creativity
 Prototypes and Screen Designs  Essential Analyst Knowledge
 Tables and Structured Lists The Making of an Analyst
 Mathematical Expressions  The Former User
Selecting Appropriate Views (ver hoja)  The Former Developer
Multiple Views  The Subject Matter Expert
Capitulo 20 Handling Requirements for Multiple Creating a Collaborative Environment
Releases Capitulo 9: Playing by the Rules
Single Requirements Specification The Rules of the Business
Multiple Requirements Specifications  Facts
Requirements Management Tools (report generated)  Constraints
Capitulo 21 Business Requirements and Business  Action Enablers
Rules  Inferences
Capitulo 22 Measuring Requirements  Computations
Ej(Product Size) Documenting Business Rules as catalog
Requirements Quality Business Rules and Requirements
Requirements Status Capitulo 12: Beyond Functionality – Software
 Proposed (someone suggested it). Quality Attributes (ver hoja)
 Approved (it was allocated to a baseline). Defining Quality Attributes
 Implemented (the code was designed, written, Defining Nonfunctional Requirements By Using
and unit tested). Planguage
 Verified (the requirement passed its tests after  TAG:  [Link]
integration into the product).  AMBITION:  Fast response time to database
 Deferred (the requirement will be implemented queries on the base user platform.
in a future release).  SCALE:  Seconds of elapsed time between
 Deleted (you decided not to implement it at all). pressing the Enter key or clicking OK to
 Rejected (the idea was never approved). submit a query and the beginning of the
Requests for Changes display of query results.
 METER:  Stopwatch testing performed on 250
test queries that represent a defined usage
Capitulo 23 Exploiting Requirements Management operational profile.
Tools  MUST:  No more than 10 seconds for 98
percent of queries. <-- Field Support Manager
Wiegers-2003  PLAN:  No more than three seconds for
Capitulo 3: Good Practices for Requirements category one queries, eight seconds for all
Engineering (ver hoja) queries.
Capitulo 4: The Requirements Analyst  WISH:  No more than two seconds for all
Requirements Analyst Role queries.
 The Analyst's Tasks Attribute Trade-Offs: Positive and negative
o Define business requirements relationships among selected quality attributes
o Identify project stakeholders and user clases Implementing Nonfunctional Requirements (ver
o Elicit requirements hoja)
o Analyze requirements Capitulo 13: Risk Reduction Through Prototyping
o Write requirements specifications Prototyping: What and Why
o Model the requirements  Clarify and complete the requirements
o Lead requirements validation  Explore design alternatives
o Facilitate requirements prioritization  Grow into the ultimate product
o Manage requirements Horizontal Prototypes or behavioral prototype
 Essential Analyst Skills (user interface)
 Vertical Prototypes or structural prototype  Inspection Stages: Planning , Overview
(functionality) meeting,  Preparation, Inspection meeting,
Rework, Follow-up
Throwaway Prototypes or exploratory prototype  Exit Criteria: revised document
(answer questions, resolve uncertainties)  Defect Checklists: (defectos comunes)  
Evolutionary Prototypes (solid architectural Requirements Review Challenges
foundation)  Large requirements documents (evitar eso) 
Paper and Electronic Prototypes (cheap, fast, and  Large inspection teams   (no mas de 2 horas)
low-tech - explore what a portion of an implemented  Geographical separation of inspectors (evitar)
system) Testing the Requirements
Prototype Evaluation (si cumple con lo solicitado)  Business requirement  
The Risks of Prototyping (usuario cree que es el  Use case  
programa final)  Functional requirement  
Prototyping Success Factors  Dialog map  
 Include prototyping tasks in your project plan.  Test case  
State the purpose of each prototype before you Defining Acceptance Criteria
build it. Capitulo 16: Special Requirements Development
 Plan to develop multiple prototypes. Challenges
 Create throwaway prototypes as quickly and Requirements for Maintenance Projects
cheaply as possible.  Begin Capturing Information
 Invest the minimum effort in developing  Practice New Requirements Techniques (data
prototypes dictionary, Drawing analysis models,
 Don't try to perfect a throwaway prototype. Specifying quality attributes, Building user
 Don't include extensive input data validations, interface, Inspecting requirements
defensive coding techniques, error-handling specifications, Writing test cases from
code, or code documentation in a throwaway requirements, Defining customer acceptance
prototype. criteria)
 Don't prototype requirements that you already  Follow the Traceability Chain (alguien lo
understand escribió, alguien lo modifico)
 Use plausible data in prototype screen displays  Update the Documentation
and reports.  Requirements for Package Solutions
 Don't expect a prototype to fully replace an SRS. o Develop Use Cases
Capitulo 14: Setting Requirement Priorities o Consider Business Rules
A Prioritization Scale o Define Quality Requirements (Usability,  
 High priority Performance,Flexibility,Integrity,
 Medium priority Interoperability)
 Low priority  Requirements for Outsourced Projects
Prioritization Based on Value, Cost, and Risk o Provide the details
Capitulo 15: Validating the Requirements o Avoid ambiguity
Reviewing Requirements o Arrange touch points with the supplier
 peer deskcheck, in which you ask one colleague
o Define a mutually acceptable change-
to look over your work product
control process
 passaround, in which you invite several
o Plan time for multiple cycles and reviews
colleagues to examine a deliverable concurrently
of requirements
 walkthrough, during which the author describes
o Define acceptance criteria
a deliverable and solicits comments on it
 Requirements for Emergent Projects
The Inspection Process
o Casual User Requirements Specification
 Participants
o On-Site Customer
 Inspection Roles: autor, inspection leader,
Reader, Recorder. o Early and Frequent Prioritization
 Entry Criteria: document cumple con standard o Simple Change Management
template, spell-checked, any layout errors, all Capitulo 17: Beyond Requirements Development
document are available, Line numbers are  From Requirements to Project Plans (Investing
printed, All open issues are marked, no more in Requirements Accelerates Development)
than three major defects. o Requirements and Estimation
o Requirements and Scheduling
 From Requirements to Designs and Code
 o A Develop a solid oChange-Control Process Description:
o Identify the key object classes Introduction, Roles and Responsibilities,
o functionality to concurrent processes. Change-Request Status, Entry Criteria(valid
change request), Tasks, Verification, Exit
 From Requirements to Tests. Criteria (Rejected, Closed, or Canceled),
oTesting (executing the software to look for Change-Control Status Reporting (Data Items
defects) Stored for Each Request)
oInspection (examining the code to ensure that  The Change Control Board
it satisfies the requirements) o CCB Composition: groups who need to
oDemonstration (showing that the product participate in making decisions
works as expected) o CCB Charter : describes the CCB's purpose,
oAnalysis (reasoning through how the system scope of authority, membership,
should work under certain circumstances) operating procedures, and decision-
 From Requirements to Success making process
Capitulo 18: Requirements Management Principles  Change-Control Tools
and Practices  Measuring Change Activity: what happened in
 The Requirements Baseline the past
 Requirements Management Procedures :  Change Isn't Free: Impact Analysis
Tools, techniques, and conventions for o Impact Analysis Procedure: Understand
controlling versions of the various requirements the possible implications, Change often
documents and of individual requirements produces a large ripple effect, product can
 Requirements Version Control reduce its performance, Identify all the
 Requirement Attributes files, models, and documents that might
oDate the requirement was created have to be modified if the team
oIts current version number incorporates the requested change,
oAuthor who wrote the requirement Identify the tasks required to implement
oPerson who is responsible the change, and estimate the effort
oOwner of the requirement or a list of needed to complete those tasks.
stakeholders o Usar: Impact Analysis Report Template
oRequirement status Capitulo 20: Links in the Requirements Chain
oOrigin or source of the requirement  Tracing Requirements
oThe rationale behind the requirement
oSubsystem to which the requirement is
allocated
oProduct release number
oVerification method to be used or acceptance
test criteria
oImplementation priority
oStability
 Motivations for Tracing Requirements:
 Tracking Requirements Status (Proposed,
Certification, Change impact analysis,
Approved, Implemented, Verified, Deleted,
Maintenance, Project tracking, Reuse, Risk
Rejected)
reduction, Reengineering, Testing        
 Measuring Requirements Management (Effort
 The Requirements Traceability Matrix: one-to-
Submitting requirements changes, proposing
one, one-to-many, or many-to-many
new requirements, Evaluating proposed
relationships between system elements,
changes, including performing impact analysis,
involucran en una tabla: User Requirement,
Change control board activities, Updating the
Functional Requirement, Design Element
requirements documents or database,
(Class catalog), Code Module, Test Case
Communicating requirements changes to
 Tools for Requirements Tracing
affected groups and individuals, Tracking and
 Requirements Traceability Procedure:
reporting requirements status, Collecting
o Select the link relationships
requirements traceability information
o Choose the type of traceability
Capitulo 19: Change Happens
o Select a mechanism for storing the data
 Managing Scope Creep(mala)
o Identify the parts of the product for which
 The Change-Control Process
you want to maintain traceability
oChange-Control Policy
 information. (critical functions, the high-  Fundamentals of Software Process
risk portions) Improvement
o Modify your development procedures oProcess improvement should be evolutionary,
o Define the tagging conventions continuous, and cyclical
oIdentify the person who will coordinate the oPeople and organizations change only when
traceability activities and manage the data. they have an incentive to do
Capitulo 21: Tools for Requirements Management o Process changes should be goal-oriented
 Benefits of Using a Requirements Management o Treat your improvement activities as
Tool miniprojects
oManage versions and changes    The Process Improvement Cycle
oStore requirements attributes  
oFacilitate impact analysis  
oTrack requirements status  
oControl access  
oCommunicate with stakeholders  
oReuse requirements  
 Requirements Management Tool Capabilities

 Requirements Engineering Process Assets (ver

hoja)
Capitulo 22: Improving Your Requirements Processes  Requirements Process Improvement Road Map
 How Requirements Relate to Other Project
Processes

Capitulo 23: Software Requirements and Risk

Management
 Fundamentals of Software Risk Management
o Elements of Risk Management

oProject planning  
oProject tracking and control  
oChange control  
oSystem testing  
oConstruction 
 Requirements and Various Stakeholder Groups o Documenting Project Risks
o Planning for Risk Management
 Requirements-Related Risks
o Requirements Elicitation
 Product vision and project scope 
 Time spent on requirements
development  
 Completeness and correctness of
requirements specifications  
 Requirements for highly innovative
products  
 Defining nonfunctional requirements  
  Customer agreement on product  Indirection: Assign the responsibility to an
requirements   intermediate object to mediate between other
 Unstated requirements components or services so that they are not
 Existing product used as the directly coupled. The intermediary creates an
requirements baseline   indirection between the other components
 Solutions presented as needs     
oRequirements Analysis
 Requirements prioritization  Protected Variations: Identify points of
 Technically difficult features predicted variation or instability; assign
 Unfamiliar technologies, methods, responsibilities to create a stable interface
languages, tools, or hardware      around them
o Requirements Specification Capitulo 18. Object Design Examples with GRASP
 Requirements understanding    Design use case realizations.
 Time pressure to proceed  Apply GRASP to assign responsibilities to
 Ambiguous terminology   classes.
 Design included in requirements    Apply UML to illustrate and think through the
oRequirements Validation design of objects.
 Unvalidated requirements  Capitulo 19. Designing for Visibility
 Inspection proficiency     Identify four kinds of visibility.
oRequirements Management  Design to establish visibility.
 Changing requirements   o A Attribute visibility B is an
 Requirements change process   attribute of A.
 Unimplemented requirements   o Parameter visibility B is a
 Expanding project scope   parameter of a method of A.
o Local visibility B is a local
Larman object in a method of A.
Capitulo 15. UML Interaction Diagrams o Global visibility B is in some way globally
 Sequence and Communication Diagrams visible.
Capitulo 16. UML Class Diagrams Capitulo 20. Mapping Designs to Code
Capitulo 17. GRASP: Designing Objects with Capitulo 21. Test-Driven Development (TDD) and
Responsibilities Refactoring
GRASP: A Methodical Approach to Basic OO Design TDD: Test code is written before the class to be
(patterns) tested
 Creator. Refactoringis a structured, disciplined method to
 Information Expert: Assign a responsibility to rewrite or restructure existing code without
the information expertthe class that has the changing its external behavior, applying small
information necessary to fulfill the responsibility transformation steps combined with re-executing
 Low Coupling (measure of how strongly one tests each step
element is connected): Assign a responsibility so Capitulo 22. UML Tools and UML as Blueprint
that coupling remains low. Use this principle to  Define forward (generation of code from
evaluate alternatives diagrams), reverse (generation of diagrams
 Controller. from code), and round-trip engineering (loses
 High Cohesion: hard to comprehend, hard to the loopthe tool supports generation in
reuse, hard to maintain, delicate; constantly either direction and can synchronize
affected by change between).
 Polymorphism: When related alternatives or  Suggestions for choosing a UML tool.
behaviors vary by type (class), assign  Suggestions on how to integrate UML wall
responsibility for the behaviorusing polymorphic sketching and tools.
operationsto the types for which the behavior Capitulo 23. Quick Analysis Update
varies. Quickly highlight some analysis artifact changes,
 Pure Fabrication: Assign a highly cohesive set especially in the Monopoly domain model.
of responsibilities to an artificial or convenience Capitulo 24. Iteration 2More Patterns
class that does not represent a problem domain 1. Simplifications in the Case Study
conceptsomething made up, to support high 2. Requirements and Emphasis: Object
cohesion, low coupling, and reuse. Design and Patterns
Capitulo 26. Applying GoF(Gang-of-Four Design
Patterns Book) Design Patterns
 Factory
Singleton
Observer

Capitulo 32. Domain Model Refinement

 Refine the domain model with generalizations,
specializations, association classes, time
intervals, composition, and packages.
 Identify when showing a subclass is worthwhile.
Capitulo 33. Architectural Analysis
 Create architectural factor tables.
 Create technical memos that record
architectural decisions.
Capitulo 34. Logical Architecture Refinement
 Explore more issues in logical architecture and
the Layers pattern, including inter-layer
collaboration.
 Present the logical architecture for this iteration
of the case studies.
 Apply the Facade, Observer, and Controller
patterns in the context of architectural layers.
Capitulo 36. Package Design
 Organize packages to reduce the impact of
changes.
 Know alternative UML package structure
notation.
Capitulo 37. UML Deployment and Component
Diagrams
Capitulo 38. Designing a Persistence Framework with
Pattern
 Design part of a framework with the Template
Method, State, and Command patterns.
 Introduce issues in object-relational (O-R)
mapping.
 Implement lazy materialization with Virtual
Proxies.
Capitulo 39. Documenting Architecture
Capitulo 40. More on Iterative Development and
Agile Project Management
 Rank requirements and risks.
 Compare and contrast adaptive and predictive
planning.

JBR
Capitulo 8: Análisis
Capitulo 9: Diseño
Capitulo 10: Implementación
Capitulo 10: Pruebas