Software Requirements (ISBN: 978-0-735-69145-2)

An important ingrediant of software process improvements.

Software Requirements
ISBN: 978-0-735-69145-2

Ch1
Errors detected during requirement phase account for 40-60% of defects (p4)

Stakeholders include: customers, users, requirement analyst, developers, testers, documenter, project manager, legal, manufacture, sales/marketing/support, etc. (p4)

Requirement (p7):1) solve user problem, 2) satisfy a condition/capability, 3) Document step 1 & 2

Software requirement includes: Business requirement, User requirement, Functional requirement (p8)

Business requirement – A high level objective in vision and scope, supported by project charter (p9)

User requirement – describes goals & task to perform.It includes use case, scenario, event/repose table (p9)
All user requirements must align with business requirement (p11)

Functional Requirement – satisfy business requirement and behavior requirement (p10)

Behavior Requirement is described in the traditional “shall” language.i.e. “The system shall email..”

Software requirement specification – Fully expected behavior of software.It is used in development, testing, quality assurance, project management (p10)

Non functional requirement include: performance goals, quality attributes (usability, portability, integrity, efficiency), external constraints (p11)

Product “features” enable satisfaction of business needs (bookmark, spell check), but they are not same as “task needed” (p11)

Requirement specification exclude:design details, project plan, testing information.
Project requirement is NOT same as product requirement (p12)

Requirement Engineering components (p13):

1) Requirement Development:Elicitation, Analysis, Specification, Validation

2) Requirement Management

Requirement development is an iterative process, and it should be planned for multiple cycles of requirement refinement (p14)

Requirement management maintains agreement between customer and software project(p14)

Requirement management includes (p14):

1) create a base line

2) review/evaluate changes

3) Approve changes in requirement

4) maintain project plan with changes

5) negotiate new estimates

6) trace requirement to their corresponding activities (design, code, test,e etc)

7) Track status

The hardest part of requirement gathering is discovering the requirement (p16)

Periodically ask and document:“what are we assuming”

Re-work account 30-50% of development costs (p17)

Requirement errors account for 70-805% of rework

Requirement risks include (p17):

1) Insufficient user involvement

2) Creep user requirement

3) Ambiguous requirement – forces developer to fill blanks, requirement can lead to different specification

4) Gold plating – Developer adding features that users will “love” (but user don't really care about it or asked for it)

5) Minimal specification

6) Overlook user classes

7) Inaccurate planning

Manage scope creep by (p18):

1) Define business objective, vision, scope, source of criteria, expected usage

2) evaluate all changes against step 1

3) Include a change process which includes: impact on stake holders, effect on resources, and trade offs

Avoid falling into trap of “here is my idea...how long do you think it'll take” (p20)

Benefits of high quality requirement (p20-21):

1) less rework

2) reduce development work

3) fewer unnecessary features

4) lower cost

5) faster development

6) fewer miscommunication

7) reduced scope creep

8) better deliverables

9) buy-in and excitement of users and stakeholder

10) minimize change control

It is a good idea to have several stakeholders review the software requirement specification (p22)

Every requirement should originate from a source that has the authority to specify requirement.Trace to use case. (p23)

Prioritize use cases and functional requirements (p23)

Create a glossy, and define all specialized terms in requirement documenter (p23)

Make sure the requirement is verifiable.

Requirement specification should be modifiable (p24):

• maintain history
• when requirement appear more than once, it is easy to introduce inconsistency.
• Cross reference to original statement

Requirement specification should be tractable (p24):

avoid lumping multiple requirements.Each requirement must link back to different design and code as well as statement.

Ch2

Business requirement is NOT enough for software development (p30)

User requirement tell the developers what task is needed

There can be conflict between business requirement and user requirements; but, at least everyone can know and resolve this in the planning stages (p30).

Sign-off establishes a base line.There should be room for review & adjustments with recognition that schedule & cost will be effected.

For a table of customer responsibility and expectations see table on p32

Requirements bill of rights for customers that can expect from business analyst:

1. Speak customer language, provide business glossary

2. Learn about customer business & system objectives; uses & understands existing systems

3. Structure the information presented by customer into written software specification

4. Explain all the work products created from requirement process (diagrams, etc)

5. Analyst & developers are respectful & professional during the whole process

6. Provide ideas & alternatives to requirements & specification

7. Describe characteristics of the product that will make it easy & enjoyable to use. Quality characteristics lead to user friendly, robust, and efficient application.

8. Adjust requirements to permit use of existing software components

9. provide good-faith estimates of costs, impacts, & trade-offs during change requirement

10. Receive a system that meets functional & quality needs that have been communicated to the developer & agreed upon.For effective communications, state assumptions, expectations, and constraints.

Requirement bill of rights for software customers that business analyst can expect:

1. Educate analyst & developer about business & define business jargons

2.Spend the time required to provide requirements, & clarify them iteratively via iterative workshops, brainstorm sessions, interviews, etc

3.Be specific & precises when providing input about the system's requirements.Instead f “to-be-determined”, use proto-typing

4.Make timely decisions about requirements of the cost & feasibility

5.Respect developer's assessment of cost & feasibility requirement

6.Set priorities with functional requirements, system features, or use cases

7.Review requirements document & evaluate prototypes

8. Communicate changes to the requirements as soon as they become known

9.Follow the development organization's process for requesting requirements & changes.Implement & utilize change process

10.Respect the process the analyst uses for requirements engineering.

Lack of customer involvement greatly increases the risk of building the wrong product (p33)

Use sign of as a project milestone, with a clear shared understanding of the activities that lead to sign-off & its implications for future changes.Don't use it as a weapon (p39).

Benefit of shared understanding of baseline requirement include (p40):

• Customer managing scope
• User confidence what they will get the right software despite initial ambiguous requirement
• Development management has confidence in scheduling and cost estimates
• Managing change that will minimize chaos.

Ch3

Recall from chapter 1, requirement engineering involves:
1. Requirement development: a) Elicitation, b) analysis, c) specification, d) validation

2. Requirement management

Requirement engineering best practices (p45)

1) Require development

a) Elicitation

• Define requirement development process; Elicit, analyze, specify & validate
• Define vision & scope; from business requirement; it should remain stable, but may change in project
• Identify user classes
• Select product champions for each user class
• Establish focus groups
• Identify use cases & concepts of operations
• Identify system events & responses
• Hold facilitated elicitation workshops; Joint Requirement Planning (JRP) an Joint Requirement Development (JRD)
• Observe users performing their jobs; create workflow & data flow diagrams
• Examine problem reports (i.e. support & help desk) to come up with rich ideas
• Reuse requirement

b) Analysis

Draw context diagrams with in environment & interface

• Create prototypes & clarify requirement
• Analyze feasibility – risk, conflict, and dependancy
• Prioritize requirement for release features
• Model the requirement; Reveal inconstant or missing requirement.Use data flow diagram, entity relation, state transition, state chart, dialog map, class diagram, sequence diagram, interaction diagram, decision table, and tree.
• Create a data dictionary & glossary
• Allocate requirement to subsystem by architect
• Apply quality function deployment 1) expected requirement, 2) normal requirement, 3) exacting requirements

c) Specification

• Adopt Software Requirement Specification Template (IEEE 830-1998)
• Identify sources of requirement & stakeholder effected by requirement
• Uniquely label each requirements
• Record business rules & traceability link between requirement and business rule
• Specify quality attributes; preferences, efficiency, reliability, usability, and relative importance

d) validation

• Inspect requirements documents; team (analyst, customer, developer, tester) reviews and examine software requirement specification, analysis model, related information for defect,
• Test the requirement; drive test from user requirement.Trace test to functional requirement & verify correctness for models & prototypes
• Define acceptance criteria; create test cases to identify message part from requirement.

2) Requirement responsibility management (p44)

a) Knowledge

• Train requirements analyst
• Educate user reps and managers about requirement
• Train developers in application domain; utilize “user buddy concept”
• Create a glossary for process, order, etc.

b) Requirement Management

• Define change control; utilize commercial defect tracking
• Establish change control board to approve/reject change requests
• Perform change impact analysis to help change control board with decisions.Use requirement traceability matrix to identify effected code, test cases, etc
• Maintain change history: who, what, why, where
• Track requirement status (proposed, approved, implemented, tested)
• Measure requirements volatility; number of proposed & approved changes per week to signal measure requirement details & understanding
• Use a requirement management tool; to track traceability & link between requirement & work
• Create requirement traceability matrix during development, not at the end of the project.Link functional requirement to design code,& test case to verify it.

c) Project management

• Select appropriate life cycle
• Base plans on requirement; develop plan & schedule iteratively
• Renegotiate commitments ; if unsuccessful, comment on unlikely deliverables
• Manage requirements risks – list risks & mitigation activity
• Track requirements efforts to determine effectiveness
• Review past lessons learned.

Software requirement overview with all stakeholders can be an effective team building activity (p46)

Functional requirement is traced to user requirement, which is traced to business requirement, which includes non-functional requirement (p47)

Requirement analysis involves refinement of the requirement enough to do realistic projections for customer and schedule (p50)

Use multiple views, because only one view isn't enough (text, graph, diagrams, etc)

Business requirement involves vision & scope document(p52)

User requirement includes use cases, event response table

Software requirement specification includes functional & non-functional requirement

Writing test cases from the requirements often reveals ambiguities & vagueness (p53)

Implementing Requirement Engineering Good practices (p58)

High Impact

a) High Difficulty

· Define requirement development process

· Base plans on requirement

· Renegotiate commitments

b) Medium Difficulty

· Identify use cases

· Specify quality attributes

· Prioritize requirements

· Adopt SRS template

· Define change-control processing

· Establish CCB

· Inspect Requirements documents

· Allocate requirements to subsystems

· Record business rules

c) Low Difficulty

· Train developers in application domain

· Define vision and scope

· Identify user classes

· Draw context diagrams

· Identify sources of requirement

· Baseline and control version of requirement

Medium Impact

a) High Difficulty

· Educate user reps & managers about requirement

· Model the requirements

· Manage requirement risks

· Use a requirements management tool

· Create requirements traceability matrix

· Hold facilitated elicitation workshops

b) Medium Difficulty

· Train requirements analysts

· Select product champions

· Establish focus groups

· Create prototypes

· Define acceptance criteria

· Perform change impact analysis

· Select appropriate life cycle

c) Low Difficulty

· Analyze feasibility

· create glossary

· Create a data dictionary

· Observe users performing their jobs

· Identify system events & responses

· Uniquely label each requirement

· Test the requirement

· Track requirements status

· Review past lessons learned

Low Impact

a) High Difficulty

· Reuse requirement

· Apply Quality Function Deployment

· Measure requirement

b) Medium Difficulty

· Maintain change history

· Track requirements effort

c) Low Difficulty

· Examine problem reports

Requirement development process is an iterative process (p59)

1. Elicitation
2. Analysis

Goto step 3, or goto step 1

1. Specification
2. Validation

Goto step 3, or step 2, or step 1

Suggested requirement development process (including quality control feedback cycles & incremental implementation based on use-case priorities)

Repeat above steps for incremental development as needed.

Ch4

Requirement analyst (p63)

= System analyst

=requirement engineer

= requirement manager,

= requirement analyst

- educates, questions, listens, organizes, translates, & maps what customer needs with what's needed and manages stakeholders.

Sample job description:www.processimpact.com/goodies.shtml

Experienced analyst can reduce cost by 1/3 compared to an inexperienced analyst (p65)

Analyst tasks are (p65-67):
1) define business requirement statement, objectives & vision

2) Identify project stakeholders & user classes

• Provide representation for each user class
• Writes down contributions desired from participants & level of participations agreed upon.

3) Elicit requirement by performing:

• Interviews
• Facilitates requirements workshops
• Document analysis
• Surveys
• Customer site visits
• business process analysis
• Work flow & task analysis
• Event lists
• Competitive product analysis
• Reverse engineering of existing systems
• Retrospectives performed on the previous projects

* Users naturally talk about functional requirement; therefore, analyst should strive to steer conversation to quality attributes like performance goals, business rules, constraints, interfaces, etc.

4) Analyze requirement to find vague requirement that will lead to ambiguity.
Specify requirement to the level that is appropriate.

5) Write requirement specification using a template

6) Model the requirement.If appropriate create amodel using tables, math models, story boards, prototypes

7) Lead requirement validation – Validate system based on requirement.Analyst should be part of: design review, code review and test cases

8) Priorities requirements

9) Manage requirements – requirement analyst is involved through out the software development cycle.He helps create, review, and execute project plan.After establishing base line, analyst focus on verification and product satisfaction.And finally, manages change-control process with the corresponding tools.

Essential skills of system analyst include (p68-70):

• Active listener
• Interview & questioning skills – interviews senior managers (which can be intimidating), manages individuals who are aggressive or opinionated.
  A lot of code is written to handle exceptions; therefore, theanalyst probes to find uncertainties, assumptions, unstated expectations, etc
• Analytic skills – must think at multiple abstractions (from high level to detailss).Critically evaluates information from multiple sources.
• Facilitates requirements elicitation workshops
• Observational skill - Actively observes & watches users to elicit new discussion.
• Reading/Writing skills – Should be critical reader, to wad through lot of material & must get idea quickly
• Organizational skills and effective coping to rapidly changing demands
• Should know many modeling techniques like:flow chart, entity relation diagrams, UML, state transition, design table, decision table, decision tree, dialog map
• Interpersonal skills – interact with many individuals; educating new colleagues and customers
• Creativity – Best analyst invent requirement that users didn't even know they had.

Essential Analyst knowledge:

Analyst can prevent issues from a program by possessing project management skills, risk management, Quality engineering, product management

Analyst application domain knowledge is a powerful thing.It helps detect unspoken assumption and addresses miscommunication.Also, makes for a better detection of gold plating.

Analysts with different backgrounds include: former users, developers, subject matter experts.Each have different strength and weakness (p71)

Ralph Young (2001) recommends that analyst be an application domain expert or a subject matter expert, and have them work with the developer/architect. (p73)

Ch5

Business request is a top level abstraction requirement, which defines vision& scope (p77)

1. If you find that you add, remove and then add back a feature, then you have a bad vision/scope (p78)

Project vision & scope help with

• feature and target releases
• change-control decisions

Some companies print a poster of the vision+scope and bring it to every meeting

Vision aligns stake holders and defines the ultimate goal. (p78)

Scope describes what portion of vision will be implemented.

For iterative enhancement, you can reference existing vision & scope. (p78)

Major new projects must have their own complete vision, scope and Software Requirement Specification.

For example:Consider a 5 year project with a primary vision & scope that has 15 sub-project; each sub-project should have its own scope and vision that aligns with the primary vision/scope.

Stakeholders have different needs, and can lead to conflicting requirements. (p80)

Resolve conflict and focus on fundamental that deliver maximum business value.

Application breath – includes business tasks (use cases) that enable application application depth. (p81)

Application depth – is a level to which each use case is implemented.

Business requirement influence implementation priorities for use-cases & functional requirements
(i.e. max profit out-weights exotic feature)

Vision & scope = project charter or business case documenter (p81)

Commercial software often create Market Requirement Document (MRD), which in addition to vision and scope, it includes more detail about the target market segments & the issues that pertain to commercial success. (p81)

Use the following template for Vision & Scope (p82 - p88)

1. Background requirements

· Backgrounds

· Business opportunity – same as market opportunity or business solution, or business process to improve.It should evaluate current solution & problems, as well as alternatives

· Business objectives & success criteria – Make sure you also state factors that have greatest impact on the success that are within or outside the organization's control.

· Customer/Market needs – Describes problem that current product does not solve, and an example of how a customer will use the solution at a high level (critical interfaces and performance measurements)

· Business risks – Competition, Timing, user acceptance, implementation issues, possible negative impact, likelihood of occurrence plus its impact, risk mitigation

1. Vision of the solution

· Vision statement – It is a realistic long term intent.The vision statement should contain the following keyword template

a) For – Target customer

b) Who – statement of the need or opportunity

c) The – product name

d) Is – a product category

e) That – Key benefit, compelling reason to buy or use

f) Unlike – primary competition, current system or current business process

g) Our product – statement of primary differentiation & advantages

· Major features – distinguishing or unique features.They should have a label (not bullet points)

· Assumptions & Dependancies – Because stakeholders may not share the same assumptions, it is important to define assumptions to align efforts.

1. Scope/Limitations – states what software will, and will NOT do.Keep a record o rejected requirements because they have a way of reappearing.

· Scope of initial release – To maintain a reasonable deliverable schedule, avoid temptation to include all features in version 1.0

· Scope of subsequent release – You can schedule additional features for iterative release with corresponding use-cases, system improvement, performance, reliability, & other quality factors.
Shorter release cycles provide frequent opportunity for learning based on customer feedback (say 90 days)

· Limitation & Exclusions – List capability that stakeholder may expect that will not be implemented.

1. Business context – provides major stakeholder profiles.

· Stakeholder profiles – You don't need to include every stakeholder.Include the influential, actively involved and effected stakeholders.

· Project priorities -

· Operating Environment – includes the availability, reliability, performance, and integrity requirement; it is often the most important element in design step.

Part of the vision & scope document might seem repetitive, but they should interlock in a sensible way.

Business requirement describes the solution benefits to the stakeholder(p83)

Examples of Financial & Nonfinancial Business Objectives and Success Criteria (p84)

Stake holder profiles should include (p88)

• Value/benefit to stakeholder (satisfaction)

o improved productivity

o reduced rework

o cost savings

o streamlined business processing automation of previously manual tasks

o Ability to perform entirely new tasks

o Compliance with pertinent standards or regulations

o improved usability compared to current products.

• Their likely attitudes towards the productivity
• Major features & characteristics of interest
• Any known constraints that must be accommodated

To have an effective decision making process, stake holders must agree on project priorities (p89)

Use 5 dimensions of software project to help set priorities

1. Feature (scope)
2. Quality
3. Schedule
4. Cost
5. Staff

Each on of the above dimensions must consider

• Constraints – limiting factor within which the project manager must operate
• Drive - A significant success objective with limited flexibility for adjustment
• Degrees of freedom – A factor that the project manager has some latitude to adjust and balance against the other dimensions.

Thus, changes can be implemented according above guideline.For example:

• Shorten test cycle duration
• Pay overtime or get outside help
• Shift resources from other projects
• Defer some requirements to a later release

Context Diagram - a graphical illustration of boundary of the scope.It shows terminal interfaces to the outside system, data, control, and material flow between terminators. (p90)

The entire system is depicted in a circle without showing system internal (processes, data, hardware/software).The terminators are rectangles (includes user classes, organizations, other systems, hardware/software, devices, or physical items).

Maintaining focus – and avoiding focus creep (p92)

• If requirement is outside the scope – you can address it in the future release
• If requirement is in scope – Include it, if it has a high priority, and you may have to cancel/defer planned requirement
• If requirement is outside scope and is a great idea because of user feedback loop – Update your vision & scope, which must go through change-control.You must also renegotiate planned budget, resource, schedule, staff, etc.

Consequence of scope creep is that completed activities must be reworked to accommodate for changes.

Documented business requirement make it easier to manage legitimate scope growth.

Ch6

To have successful project, you want to get customer’s voice to the developer’s ears (with minimal layers in between) p95

Source of requirements (p96):

· Users

· Documents – Stake holders & legal docs, competitive product reviews

· System Requirement Specification – from high level system requirement of system

· Marketing survey & questionnaire

· Observing Users at work – can identify new processes & validate requirement

· Scenario Analysis

· Even& responses that must be meet

Stake holders -> Product Customers -> Product User Classes:

• Frequent user
• Domain expert
• Feature use
• Specific task orientation
• Access level

Favored user class:Effects your delivery; he can accept/reject it. (p98)

Disfavored user class: Should not use the product (i.e. legal or safety reasons)

Non-human user class: interface to other dardware/software

1^st Brainstorm user class, 2^nd group classes with similar needs; do not exceed 15 user classes (p99)

For each user class document characteristics, responsibility, location, relative size, transition, etc to help prioritize and assess impact (p100)

Create persona for each user class (p101)

User representative should be involved throughout the development life cycle, not just in isolated requirement phase at the beginning.Each user class needs to be represented. (p101)

One study showed that highly successful project used more kinds of communication links and more direct links between developers and customers than did less successful projects. (p102)

Recognize the risk that you assume when you use surrogate (subject matter expert, marketing, product manager, etc) for actual voice of the customer. (p103)

Product champions collect requirement from other members of their class; and I ideally they are part of the user class.

Product champions have clear vision of the system and are enthusiastic about what it will offer.They understand application domain and system environment very well.They are in high demand with other activities; therefore, consider providing incentives and public recognition to obtain them. (p103)

Product champions should have binding decisions for their user classes; they should also be in contact with their peers (p104)

You may consider getting external product champions by soliciting their services, providing discounts, etc. (p104)

Watch out for product champions that are no longer current with real users

Product champion responsibilities include (p105):

• Planning – help with scope, interface to system, impact, transition path from current system
• Requirement – gathering, scenario & use cases, resolve conflict between requirements, prioritize, quantity performance, evaluate prototype
• Validation & Verification – check documents, define acceptance, test cases, test data, beta test,
• User aids – write user help, training materials, product demo
• Change management – defect management, feature manage, impact analysis

You can create a hierarchy of product champion for complex projects.

Careful with lead users: The product champion Rebeca was power user, but 90% of users weren’t; thus, the project suffered.

Product champion makes decision at the user level requirements.The management sponsor retains the authority to make decisions that affect the product vision, project scope, schedule, and cost.Document & negotiating product champion’s role and responsibilities give candidate champions a comfort level about what they’re being asked to do. (p108)

Insufficient user involvement is well established as a leading cause of software project failures (p108)
Product champions mitigate risk.

Keys to watch out for:

• Product manager overrides product champion
• Product champion has self interest
• Lacks mental image of the system; therefore, defers responsibility to analyst
• Doesn’t represent user class

You may get conflicting requirements from different user classes.Every group should select an appropriate “decision rule” – an agreed-upon way to arrive at a decision. (p109)

For example:

• Product champion resolves user class conflict
• You select the highest to users
• Use business objective to make decision

Typically, custmer should override developer/customer conflicts; but not always. Customer isn’t always right.Decide before hand, if the developer or marketing, or whoever, will make the final decision (p111)

Ch7
Focusing on user task rather than interface helps keep focus on track (p114)

Project plan elicitation should include:

• Elicitation objective
• Elicitation strategy
• Result of elicitation
• Schedule & resource estimates
• Elicitation risk

Focus on domain “verbs” instead of computer jargon (p115)

Create domain glossary & don’t assume anyone understands any of the terms

Probe around exceptions and document the reason for process.Ask:

• What else could …
• What happens when …
• Would you ever need …
• Where do you get …
• Why do you (or don’t you)…
• Does anyone ever …

Instead of simply transcribing, a good analysts makes suggestions during requirement gathering (p116)

Understand why user wants something, can lead to realization that a process that is obsolete (p116)

Shortly after interview, document your findings and send to users to review in order to identify errors & uncertainties.

Link user and developer in elicitation workshops (p117)

Have an outside facilitator lead the workshop instead of the analyst, so that the analyst can focus on requirement gathering (p117)

Elicitation workshop ground rules (p117-118)

• Starting & ending meetings on time
• Returning from breaks promptly
• Holding only one conversation at a time
• Expecting everyone to contribute
• Focusing comments and criticism on issue, not on individuals

Staying in scope - The facilitator will have to reel in the elicitation participants periodically to keep them on topic.

Use parking lot for writing down ideas

Use time box – allocate fixed period of time to each discussion on topic (say 30 minutes); discussion might need to be completed later.

Classify the voice of customer into following categories (p121)

• Business requirement
• Use cases or scenarios
• Business rules
• Functional requirements
• Quality attributes
• External interface requirements
• Constraints
• Data Definitions
• Solution Ideas
• Not software, for example: training
• Project constraints – cost, schedule, etc
• Assumptions
• Data requirements
• Additional information – historical, context-setting, descriptive nature

You can create use cases by asking users describe their business workflow, or by asking users to state their goals (p121)

Functional requirements describe observable behavior the system will exhibit under certain conditions an d the actions the system will let the users take (p122)

Business rules is NOT functional requirement

In your requirement statements replace “should” with “shall”.Make it clear that the item is required. (p122)

Listen for ambiguous terms that need to be quantified and explained: fast, easy, intuitive, user-friendly, robust, reliable, secure, efficient. (p122)

Record rational behind each constraint.Is it truly a restrictive limitation, or is it desirable goal. (p123)

Weak words like “identically”, “consistent” need to be clarified and the real constraint stated precisely enough for developers to act on the information. Ask why the constraint exists, verify its validity, and record the rational for including the constraint as a requirement (p124)

Data definitions sometimes lead to functional requirements (for example 6 digit field may not roll-over)

Embedding a solution idea in a requirement imposes a design constraint on that requirement (i.e. drop down list of my xxx).Make sure the constraint is there for a good reason.

When the scope is too large, then you have possibly collected more data than is needed to deliver adequate business & customer value (p125)

Requirements are about what the system has to do,
whereas how the solution will be implemented is the realm of design.
Nothing is perfect; thus, there is a grey area to consider.

Regard the models and screens generated during requirements developments as conceptual suggestion to facilitate effective communications, not as constraints on the options available to the designer.Make it clear to users that these screens and prototypes are illustrative only. (p126)

If your project requires extensive research, use an incremental development approach to explore the requirements in small, low-risk portions. (p126)

Decompose high level requirements until it reveals what is needed for implementations (p126)

Imprecise, fuzzy terms to avoid include: support, enable, permit, process, and manage (p127)

Have use cases for all the user classes
Trace all requirements to functional requirements
Check boundary requirements < = >
Represent requirements in multiple ways (picture) to realize message peaces
Use decision table or decision tree to insure you have all paths determined.

Create CRUD matrix f or a rigorous way to search for missing requirements.Sometimes L is add to make CRUDL = Create, Read, Update, Delete, List (p128)

Possible signals that you might be finishing with requirements:

• Users tend to identify use cases in sequence of decreasing importance
• New cases yield to existing functional requirements you may have covered
• Request is out of scope
• New requirements are all low priority
• Proposing an item that is intended for the life of the product, but it is being introduced early

in life of product

Checklist of common functional areas: Errors, Logs, Backup/Restore, Security, Reporting, Printing, Preview, Configure User preferences (p129)

Ch8

Scenario is a description of a single instance of usage of the system. (p132)

The objective of the use-case approach is to describe all tasks that users will need to perform with the system.(p133)

In Use case diagram, the ellipse bubble is the “use case”, the stick figure is the actor, and the bounding box is system (p134)

Use case is a collection of related usage scenarios, and scenarios is a specific instance of a use case. (p134)

Essential elements of use-case include:

A unique identifier

• A label in form of “verb + object”; i.e. place an order
• Short description
• Precondition
• Post condition
• Sequence and interaction steps

Use case will typically outlines the normal flow of a scenario, followed by secondary (alternative) paths of scenario (p135).

You can define a separate use case that contains the shared functionality and indicate that the other use cases include that sub use case. (p136)

Exceptions are sometimes regarded as a type of alternative course (p137)

You must implement the exceptions that can prevent the scenarios (p137)

Preconditions and post conditions define the boundaries of the individual use cases that can be chained together to perform a larger task. (p137)

To identify use cases, , Find actor then business process for each case.
Or, Express business process into -> Scenario -> then into use case

Some requirements do not trace to use cases; thus, determine if they are really needed. (p138)

Prior to beginning the workshop, each analyst asks the users to think of tasks that they would need to perform with the new system.Each these tasks are candidates to use cases. (p138)

Essential use case – focus should be on the goal the user is trying to accomplish and the system’s responsibility in meeting the goal.These are higher level abstractions of concrete use cases. (p139)

Concrete use case – discuss specific actions the user takes to interact with the system (p139)

Essential use cases are more reusable than concrete use cases.

Preconditions and post conditions are boundaries of use cases.

Estimating the frequency of use provides an early indicator of concurrent usage and capacity requirements. (p139)

Fully and Casually dressed use-case template (p143)

Fully dressed use-cases are valuable when:

• Your representatives are not closely engaged with developers
• Application is complex
• The use-case is the lowest level requirement that the developer will receive
• Develop comprehensive test cases
• Collaborating remote teams need a detailed, shared group memory

You can use two column representation for use-case; where the left column maybe user activity, and the right column the system responses (p143)

Your use-cases need to be enough to enable developer, not simply create extra work (p144)

Give use-case description to your attendees before next workshop for them to review.
Leave at least one day between successive workshops.The mental relaxation that comes after a day or two away from an intellectually intensive activity allows people to examine their earlier work from a fresh perspective. (p144)

During the final elicitation workshop, participants that walk through test cases that they’ve agreed upon, usually find additional errors in both requirements and use-cases. (p145)

Use-cases & functional requirements don’t contain all the information that a developers needs to write a software (i.e. communication protocol with bank)
Requirement analyst explicitly specifies the detailed functional requirements necessary to implement each use case (p145)

Transition from user’s view of the requirements to the developer’s view is one of the many ways the requirements analyss adds value to the project (p146)

Cross-reference functional requirements that appear in multiple use cases.In some instances, the use-case includes relationships. (p146)

The use-case description for the functional requirements, provide traceability between use-cases and corresponding functional requirements. (p146)

The use case approach leads to functional requirements that will allow the user to perform certain known tasks.This helps prevent “orphan functionality” (those that seem good idea during elicitation, but no one uses because they don’t relate directly to the user task) – p147

Use Case guidelines (p148-149)

• Use case explosion!Consider writing normal course, alternative course, and exceptions as scenarios within a single use case
• Select one success path through the use case, with one combination of true and false values for the various logical decision, and call that the normal course.Use alternative courses for the other logic branches.
• When including user interface design in the use case, make sure everyone knows that it’s not how the screen will look; because it may introduce unnecessary constraints.
• Collect data definitions in a project-wide data dictionary
• Write use cases from the user’s perspective, not the system’s point of view.
• It is risky to expect a new information system to drive the creation of an effective business process that doesn’t exist

Event-response table are particularly appropriate for real-time control systems.For example: Actor, sensory, device, external database, time event. (p150)

Event response table records information at the user-requirement level.
The table can also serve as part of the functional requirement. (p150-151)

Ch9

Business rules include (p155):

• Facts – immutable truth
• Constraints – can include keywords: must, must not, may not, only
• Action Enablers – conditions for action – IF something THEN action
  Rule that triggers some activity under specific condition (p157)
  Decision tables can provide a concise way to document action-enabling bus rule
• Computations – performed using specific algorithm/formula (i.e. income tax withholding)
• Inference – IF something THEN fact
  “Then” clause of an inference implies a fact or a piece of information, not an action to be taken.
  Computational rules can normally serve as software requirements as they are stated. (p158)

Write your business rules at the atomic level (cannot be decomposed any more), rather than combining many details into a single rule.
Consider using atables to simplify rules or other info.For example:

Commercial rule-management tools become valuable if your rules catalog outgrows a word processor or spreadsheet solution. (p160)
For a list of business rule management products see:http://www.businessrulesgroup.org/brglink.htm

As you identify new rules while working on an application, add them to your catalog rather than embedding them in the documentation for specific application (p160)

Templates describe patterns of keywords and clauses that structure the rules in a consistent fashion.They also facilitate storing the rule in a database.

You discover business rules by asking questions from different perspectives (p162):

• Policies – why do we have to do it like that?
• Data models – How are these pieces of data related?
• Actor decisions – What may the user do next?
• Events – What can and cannot happen?
• System Decisions – How does the system know what to do next?
• Object life cycle – What causes a change in the object’s state?
• Formulas - How is that number calculated?
• Regulations – What does the government require?

Linking business rule and functional requirement (P163):

• Use a requirement attribute called “origin” and indicate the rules as the origin of the functional requirement
• Define traceable links between a functional requirement and the pertinent business rules in the requirements traceability matrix.

Rules are external statements of policy that must be enforced in software, thereby driving system functionality (p163).

Don’t duplicate rules from your business rules catalog in the SRS.Instead the SRS should refer back to the specific rules as the source of, say, algorithms from income tax withholding (p164).

Rules that make sense in isolation might not be so sensible when viewed inan operation context with other requirements. (p164)

Once you begin actively looking for, recording, and applying business rules, the rationale behind your application development choices will become clearer to all stakeholders (p164).

Ch10
Vision & Scope document contains the business requirements. (p165)
User requirements often are captured in form of use-cases.
The product’s detailed functional and non-functional requirements reside in software requirements specifications.

Structured natural language, augmented with graphical models, remains the most practical way for most software projects to document their requirement. (p165)

The requirements can be stored in a database, such as a commercial requirement management tool.They are only as good as the quality of the information they hold. (p166)

Software requirement specification (p166)
= Functional specification
= Product specification
= Requirement document
= System specification
It should not contain design, construction, testing, or project management details

Several audience rely on SRS: Customers, project managers, developers, testing group, maintenance and support, document writers, education materials, legal staff, subcontractors base their work on, and can be legally held to SRS. (p167)

As the ultimate repository of the product requirement, the SRS must be comprehensive (p167).

You don’t have to build requirement for the entire product before beginning development, but you do need to capture requirements for each increment before building that increment. (p167)

Every project should baseline an agreement before the team begins implementation.

Baselining is the process of transitioning a SRS under development into one that has been reviewed and approved.

Use hyperlinks to let the reader jump to related sections in SRS. (p168)

Every functional requirement must be uniquely and persistently indentified (p168)
For a sequence number, it must not be reused if a requirement is deleted.

Hierarchical numbering (3.2.1.4) indicate level of detail, but are not persistent labels (when deleted).
Consider using a short text code followed by sequence.For example:“Section 3.5 – Editor Function”…Labels: ED-1, ED-2.(p168)

Hierarchical Textual text “Print.ConfirmCopies” drawback that they are bulkier than numeric labels. (p169)

Use notation TBD (to be determined) to flag knowledge gaps. (p169)
Resolve all TBD before implementation; otherwise, the developer may guess.

Record who is responsible for resolving each TBD issue, how, and by when.Number TBDs to help track them to closure. (p170)

Screen layouts don’t replace user and functional requirements (p170)
User Interface displays can assist with project planning and estimation.Counting GUI elements or number of functions points associated with each screen yields a size estimate, which leads to an estimate of implementation effort. (p170)

A sensible balance is to include conceptual images – sketches, etc, without demanding that the implementation precisely follow those models. (p170)

For SRS template see IEEE 1998b, or appendix D (p171)

If section heading does not apply, leave the section heading in place but indicate that it isn’t applicable.This will keep the reader from wondering whether something important was omitted inadvertently. (p171)

In SRS, include date of a change, who made the change, and the reason for the change.

Requirement “purpose” should include the revision or release number (p172)

In Project scope, related the software to user or corporate goals and to business objectives and strategies. (p173)

For new or next product version, include context and the origin of the product. (p173)

List the major features of the product in 2.2, and then the details in section 3 (p174)

Identify the favored user classes.User classes represent a subset of the stake holders (p174)

Operating environment include hardware platform, operating system (and version), geographical locations of users, servers, databases.List any other software components or applicatons with with the system must peacefully coexist. (p174)

Under design constraints specified specific technologies to use or avoid (p174)

List the user documentation components that will be delivered along with the executable software.Identify any required documentation delivery formats. (p175)

Under assumption, identify any dependencies the project has on external factors outside its control (p175)

System features can be organized by: functional requirements, use case, mode of operation, user class, stimulus, response, object class, or functional hierarchy (IEEE 1998b)

In requirement management tool define a requirement attribute of priority (p176)

In functional requirements, describe how the product should respond to anticipated error conditions and to invalid inputs and actions.

Uniquely label each functional requirement (p176)

A complex system with multiple subcomponents should use a separate interface specification or system architecture specification (p176)

For performance requirement – explain rationale to guide the developers in making appropriate design choices. (p178)

Safety requirements – Is a software rule that ensures safe system for environment or users or system.
Safety and security, integrity, privacy are examples of quality attributes (p179)

Software quality attributes – are quantitative, verifiable.They should include relative priorities to other attributes.

Other requirements to include: currency, date formatting, language, international regulation, cultural & political issues, legal requirement, operations, administration, maintenance. (p180)

Create appendix A for Glossary - all your acronyms (p180)
Create appendix B for analysis models - dataflow, class diagrams, state-transition, entity-relation
Create appendix C for Issue List – requirement issues that remain to be resolved (TBD)

Employ use terminology, instead of computer jargon (p181)
Keep sentences and paragraphs short and direct
Use terms consistently; watch out for synonyms; don’t vary your language
Decompose a vague top0level requirement into sufficient details to remove ambiguity
Follow action verbs consistently; “the system shall…”, “the user shall…”
Use “must”, and “shall”,
Avoid “should”, “may”, “might”, and any items that don’t clarify if it required.
Identify specific actor whenever possible (system or user)

Ambiguous terms to avoid: acceptable, adequate, as much as practicable, at least, at a minimum, not more than, not to exceed, between, depends on, efficient, fast, rapid, flexible, improved, better, faster, superior, including, including but not limited to, and so on, etc, such as, maximize, minimize, optimize, normally, ideally, optionally, reasonable, when necessary, where appropriate, robus, seamless, transparent, graceful, several, shouldn’t, state-of-the-art, sufficient, support, enable, user-friendly, simple, easy (p183-184)

Provide enough detail in the requirement to reduce the risk of misunderstanding to acceptable level based on the development team’s knowledge and experience. (p184)

A helpful guideline is to write individually testable requirements.If you can think of a small number of related test cases to verify that a requirement was correctly implemented, it’s probably at an appropriate level of detail. (p184)

Testable requirements have been proposed as a metric for software product size (p184)

Avoid long narrative paragraphs that contain multiple requirements with words like: “and”, “or”, “also”

Never use “and/or” in a requirement; it leaves the interpretation up to the reader.
Words such as “Unless”, and “except” also indicate multiple requirements. (p184)

Cross-reference related items in the SRS to help keep them synchronized when making changes (p184)

Think about the most effective way to represent each requirement; see if there is a pattern in a table.

High quality requirement is: complete, correct, feasible, necessary, prioritized, unambiguous, verifiable. (p185)

Data dictionary – a shared repository that defines the meaning, data type, length, format, necessary precision, and allowed range or list of values for all data elements or attributes used in the application. (p190)

Begin collecting data definition as you encounter them during requirement.
Data dictionary complements project glossary. (p190)

I you set up the data dictionary manually, consider using hypertext approach.

Data dictionary notations:

Primitive – defined with a comment, which is a text between two asterisks:
Requset ID = * this is 6 digit unique id, generated by the system *

Composition – a data structure; optional items are enclosed in parentheses:
Requested Chemical = Request Id
+ Number of containers
+ Grade
+ Amount
+ (Vendor)

Iteration – If multiple instances of an item can appear in data structure, they are enclosed in curly braces
Request = Request Id
+ Request Date
+ Charge Number
+ 1:10 {Requested Chemical}

Selection – enumerated primitive
Quantity Units = [“grams” | “kilograms” | “milligrams” | “each”]
* 9 character text string indicating the units associated with the quantity of chemical requested *

Note: each data item is also declared in dictionary

Ch11

Functional requirements include: lists, tables, graph analysis model, interface prototype, test case, decision tree, decision table(p194)
UI designer should build the prototype
Test leads writes the test cases

An early goal of structured system analysis was to replace entirely the classical functional specification with graphical diagrams and notations more than narrative text (p194)

Visual requirements include: Data Flow Diagrams (DFD), Entity-Relations-Diagrams (ERD), State-Transition Diagrams (STD)

Diagrams let you model the problem domain or create conceptual representation of the system. (p194)

During design, models represent specifically how you intent do implement the system: the actual database you plan to create, the object classes you’ll instantiate, and the code modules you’ll develop. (p195)

Don’t assume that developers can simply translate analysis models into code without going through a design process.Because both types of diagrams use the same notations, clearly label each one as an analysis model (the concepts) or a design model (what you intend to build)

Case tools know the rules for each modeling method they support.They can identify syntax errors and inconsistencies that people who review the diagrams might not see. (p195)

Focus your modeling on the most complex and riskiest portions of the system and on those portions most subject to ambiguity or uncertainty. For example:security, safety, mission critical system (p195)

Relate customer’s voice to analysis model: (p196)

For example:A chemist (noun) or a member of the chemical stockroom staff (noun) can place(verb) a request (nount)….

Data Flow diagram is the basic tool for structured analysis (p197)

DataFlow diagram identifies:

• Transformational processes
• The flow of data between processes and storage
• Functional decomposition to break complex problems
• Works well for transaction process systems
• Represent multi-step activity

Make sure you explain the purposeand notations of each model to your product champions and ask them to review the diagrams.Don’t assume they understand it (p197)

Context Diagram is the highest level of abstraction of Data Flow Diagram (p197-8)
Circles represent major processes (black box); the rectangles represent information terminators; Arrow are the directions of the flow; and the parallel horizontal lines are the data storage.

Each process that appear as a separate bubble (circle) on the level 0 diagram can be further expanded into a separate DFD to reveal more details.
Lowest-level diagram contains only primitive process operations that can be represented in a narrative text, pseudo code, flowchart, or an activity diagram.
Functional requirement of SRS defines what happens with lowest level of DFD. (p199)

Data Flow Diagram guidelines:

• Place data stores only on the level 0 DFD and lower levels, not on the context diagram
• Processes communicate through data stores.Data cannot flow directly from on e store to another
• Don’t’ attempt to imply processing sequence using DFD
• Name each process as a concise action: verb plus object (such as Generate Inventory Reprots)
• Number process uniquely and hierarchically.For example 3.2
• Don’t show more than 8-10 process on a single diagram.Introduce a level of abstraction by grouping
• Bubbles with flows that are only coming in or only going out are suspect.Normal processes require both input and output.

An analysis of Entity Relation Diagram (ERD) help you understand and communicate the data components of the database.In contrast, when you create ERD during system design, you’re defining the logical or physical structure of the system’s database. (p200)

Entities are named as a Singular noun in a rectangle.
Cardinality or multiplicity of each relationship is shown with a number or letter on the lines that connect entities and relationships.Below is an example of Partial entity-relationship diagram (p201)

State change can take place only when well-defined criteria are satisfied, such as receiving a specific input stimulus under certain conditions. (p203)

System elements that involve a set of states and changes between them can be regarded as finit-state machines (p203)

State transition diagram (STD) provides a concise, complete, and unambiguous representation of a finite-state machine.
A related technique is State chart diagram defined in UML.

STD contains three types of elements: (p203)

• States are shown as rectangles or ovals
• Transitions are shown as arrows
• Events or conditions that cause the transition to take place are shown as text lables on each transition arrow.

STD doesn’t show the details of the processing (p204)
STD helps developers understand theintended behavior of the system

STD makes it easier to step back from the detailed level and see the big picture; however, it does not provide the details that a developer needs. (p206)

User interface can be regarded as finite state machine (p206)

Many user interfaces can be modeled with a form of state-transition diagram called dialog map.

Dialog map represents a user interface design at a high level of abstraction.It doesn’t show the detailed screen design (p206).

Dialog maps are related to system story boards (p207)

Just as in an ordinary state-transition diagrams, the dialog map shows each dialog elements as a state and each allowed navigation option as a transition (arrow).The condition that triggers a user interface navigation is shown as a text labeled on the transition arrow.

Dialog map triggers for UI include: (p207)

• User action, such as pressing a function key or click a hyperlink or dialog box button
• A data value, such as an invalid user input that triggers an error message display
• A system condition, such as detecting that a printer is out of paper
• Some combination of these; such as typing a menu option number and pressing the enter key.

A flowchart explicitly shows the processing steps and decision points;
In contrast, the dialog map does not show the processing that takes place along the transition lines that connect one dialog element to another.Branch decisions or user choices) are usually hidden. (p207)

Think of dialog map as a negative image or a complement to a flow chart

To simplify dialog map, omit global functions such as pressing the F1 key to bring up a help display from every dialog element. Omit the transitions that reverse the flow of a page(p207)

Users get annoyed if they are forced to complete a task even though they change their minds partway through it.The dialog map lets you enhance usability by designing in those back-out and cancel options at strategic points (p208)

Don’t try to pin down all the user interface design details at the requirement stage.Instead, use models to help the project stakeholders reach a common understanding of the system’s intended functionality.

A class diagram is a graphical way to depict the classes identified during object-oriented analysis and the relationships among them. (p210)

Use decision tables and decision tress when complex logic an decisions come into play.(p212)

The factors can be shown either as statements with possible conditions of true and false or questions with possible answers of yes and no.You can also have decision tables with more than two possible values (p212)

Sample decision table:

You don’t need to create every kind of diagram, as they may present similar information.For example,

If you create an ERD and data dictionary, you might not want to create a class diagram (or vice versa). P214

Ch12
Software quality attributes answer: How easy it is to use, How quickly it runs, How often it fails, How are the exceptions handled (p216)

Meeting nonfunctional requirements are often more important than meeting the functional requirements (p216)

If you don’t explore the customers’ quality expectations during requirements elicitation, your just lucky if the product satisfies them (p216)

Customers generally don’t present their quality expectations explicitly.The trick is to pin down just what the users are thinking when they say the software must be user-friendly, fast, reliable, or robust. (p217)

A way to classify quality attributes is by classifying them as runtime from those that aren’t.
Another approach is to separate the visible characteristics that are primarily important to the users , and are significant (under the hood) for the technical staff (p217)

Software quality attributes to consider: (p217)

Document any global quality goals in section 5.4 of the SRS template presented in chapter 10. (p218)

Rank each attribute on scale of 1 (don’t give it another thought) to 5 (critically important.

Craft specific measurable, verifiable requirements for each attribute.(p218)
Target minimum and maximum values

IEEE standards for a software quality metrics methodology presents an approach for defining software quality requirements in the context of an overall quality metrics framework. (p218)

Consider asking users what would constitute unacceptable performance, usability, integrity, or reliability. (p218)

Availability is a measure of the planned up time. (p219)
Formally, availability equals the mean time to failure (MTTF).

Some authors view availability as encompassing reliability, maintainability, and integrity (p219)

Efficiency is a measure of how well the system utilizes processor capacity, disk space, memory, or communication bandwidth.Efficiency is related to performance, another class of nonfunctional requirement. (p220)

To allow engineers margins for unanticipated conditions and future growth, you might specify something like the following:EF-1. At least 25% of the processor capacity and RAM availability to the application shall be unused at the planned peak load conditions. (p220)
Typical users wont state efficiency requirements in such technical terms.

Flexibility = extensibility = augmentability = extendibility = expandability (p221)
FL-1. A maintenance programmer who has at least six months of experience supporting this product shall be able to make a a new hardcopy output device available to the product, including code modifications and testing, with no more than one hour of labor.

Integrity – encompasses security – Integrity has no tolerance for error.Examples include: user identity verification, user privilege levels, access restriction ) p222
IN-1. Only users who have Auditor access privilege shall be able to view customer transaction histories.

Interoperability indicates how easily the system can exchange data or services with other systems.
To assess interoperability, you need to know which other applications the users will employ in conjunction with your product and what data they expect to exchange.
IO-1 The chemical tracking system shall be able to import any valid chemical structure from the ChemiDraw (version 2.3or earlier) and Chem-Struct (version 5 or earlier) tools.

You could also state this requirement as an external interface requirement and define the standard file formats (p222)

Reliability – the probability of the software execution without failure for a specified period of time. The average length of time the system runs before failing. (p223)
RE-1. No more than five experimental runs out of 1000 can be lost because of software failures.

Robustness is sometimes considered an aspect of reliability.

Systems that require high reliability should also be designed for high testability to make it easier to find defect that could compromise reliability (p223)

Robustness – is the degree to which a system containues to function properly when confronted with invalid inputs, defects in connected software or hardware components (recovers gracefully).It is a function of fault tolerance. (p223)
RO1. If the editor fails before the user saves the file, the editor shall be able to recover all changes made in the file being edited up to one minute prior to the failure the next time the same user starts the program.

Usability (human engineering) measures the effort t required to prepare input for, operate, and interpret the output of the product. (p224)
us-1. A trained user shall be able to submit a complete request for a chemical selected from a vendor catalog in an average of four and a maximum of six minutes.

Maintainability indicates how easy it is to correct a defect or modify the software.
It is closely related to flexibility and testability (p225)

You can measure maintability in terms of the average time required to fix a problem and the percentage of fixes that are made correctly (p225)
MA-1. A maintenance programmer shall be able to modify existing reports to conform to revised chemical-reporting regulations from the federal government with 20 labor hours or less of development effort.
MA-2. Function calls shall not be nested more than two levels deep
MA-3. Each software module shall have a ratio of nonblank comments to source code statement of atleast 0.5

Portability – the effort required to migrate a piece of software from one operating environment to another.Some practitioners include the abilityto internationalize and localize a product under the heading of portability. (p226)

Portability goals should identify those portions of the product that must be movable to other environments and describe those target environment. (p226)

Reusability – software that must be modular, well documented, independent of a specific application and operating environment, and somewhat generic in capability.Reusability goals are hard to quantify (p226)
RU-1. The chemical structure input functions shall be designed to be reusable at the object code level in other applications that use the international standard chemical structure representations.

Testability = Verifiability; ease of which product can be test.
It is critical if the product has complex algorithms, or the product will be modified often (p227)
TE-1. The maximum cyclomatic complexity of a module shall not exceed 20.

Cyclomatic complexity is a measure of the number of logic branches in a source code module.
Adding more branches and loops to a module makes it harder to test, to understand, and to maintain (p227)

Performance requirement encompass speed (database response times, for instance), throughput (transactions per second), capacity (concurrent usage loads), and timing (hard real-time demands)

Performance requirements should also address hos the system’s performance will degrade in an overloaded situation. (p227)
PE-1. The temperature control cycle must execute completely in 80 milliseconds

Unverifiable quality requirements are no better than unverifiable functional requirements. (p228)

Planguage – a planning language with a rich set of keywords that permits precise statements of quality attributes and other project goals (95% of catalog database queries shall be completed within 3 seconds on a single-user 1.1-GHz Intel Pentium 4 PC running MS windows XP with at least 60% of the system resources free). (p228)

TAG – Performance.QueryResponseTime

AMBITION – Fast response time to database queries on base user platform

SCALE – Seconds of elapsed time between pressing the Enter key or clicking OK to submit a query and the beginning of the display of query result.

METER – Stopwatch testing performed on 250 test queries that represent a defined usage operational profile

MUST - No more than 10 seconds for 98% of queries ß Field support manger

PLAN – No more than 3 seconds for category one queries, 8 seconds for all queries

WISH – No more than 2 seconds for all queries

Base user platform DEFIND – 1.1-GHz Intel Pentium 4 processor, 128 MB RAM, MS windows XP, QueryGen 3.3 running, single user, at least 60% of system resources free, no other application running.

Each requirement receives a unique tag, or label.(p228-229)
The ambition states that the purpose or objective of the system that leads to this requirement.
Scale defines the units of measurement
The meter describes precisely how to make the measurements
The must criterion is the minimum acceptable achievement level
The plan value is the nominal target
The wish value represents the ideal outcome
See http://www.gilb.com/ for the most recent information on the still-evolving Planguage vocabulary and syntax.

Planguage provides a powerful ability to specify unambiguous quality attribute and performance requirements. (p229)

Determine conflict goals so that you can commit accordingly.
Change a row effects the column (p230)

Translating quality attributes into Technical Specification (p232)

Ch13

Software prototype is a partial or possible implementation of a proposed new product. (p234)

• Clarify and complete the requirements
• Explore design alternatives
• Grow into the ultimate products

Primary reason for creating a prototype is to resolve uncertainties early in development process (p234)

Horizontal prototype = Behavioral prototype = mock-up – doesn’t dive into all layers of an architecture; it depicts a portion of the user interface; the goal is the refining requirements (p234)
It contains little or no real functionality.
It can demonstrate the functional options the user will have available; navigations might work. (p235)

Vertical prototype = structural prototype = proof of concept – works like the real system
It touches on all levels of the system implementation.
Typically constructed using production tools in a production-like operating environment.
You’re uncertain whether a proposed architectural approach is feasible and sound (p236)

Throwaway Prototypes = exploratory prototypes – resolve uncertainties, and improve requirements quality.It emphasizes quick implementation and modification over robustness, reliability, performance, and long-term maintainability. Thus, don’t allow such low-quality code from a throwaway prototype to migrate into a production system.
It’s appropriate when a team faces uncertainty, ambiguity, incompleteness, or vagueness in the requirement.(p237)

Each use-case description includes a sequence of actor actions and system responses, which you can model using a dialog map to depict a possible user interface architecture.

When users evaluate the prototype, their feedback might lead to changes in the use-case description or to changes in the dialog map (p237)

Evolutionary prototype (contrast to throwaway) – provides solid architectural foundation for building the product incrementally as the requirements become clear over time.
Evolutionary prototyping is a component of the spiral software development cycle model.
It is built with robust, production-quality code from the outset.
It is designed for easy growth and frequent enhancement.
The first increment of an evolutionary prototype can be thought as pilot release.
Work well for applications that you know will grow over time. (p238)

Paper prototypes help you test whether users and developers hold a shared understanding of the requirements; it is similar to storyboard. (p240)
Sometimes users are less eager to critique a lovely computer-based prototype.
Developers, too, might resist making substantial changes in a carefully crafted electronic prototype. (p240)

No matter how efficient your prototyping tools are, sketching displays on paper is faster (p241)

Paper prototyping is an excellent technique for refining the requirements prior to designing detailed user interfaces, constructing an evolutionary prototype, or undertaking traditional design and construction activities. (p241)

To improve the evaluation of horizontal prototypes, create scripts that guide the user through a series of steps and ask specific questions to elicit the information you need.(p242)
Derive the evaluation scripts from the use case or functions that the prototype addresses.Questions to ask consider regarding prototyping:

• Does the prototype implement the functionality in the way you expected
• Is any functionality missing
• Can you think of any error conditions that the prototype doesn’t address
• Are any unnecessary functions present
• How logical and complete does the navigation seem to you
• Were any tasks overly complex

During prototype evaluation include both experienced and inexperienced user class representatives (p242)

You’ll learn more by watching users work with prototype than by just asking them to tell you what they think of it.
Watch where user’s fingers try to go instinctively.
Look for the furrowed brow that indicates a puzzled user who can’t tell what to do next.
Look for user take a side trip to another part of application to look something up.
Ask evaluators to share their thoughts aloud as they work with prototype.
Create a nonjudgmental environment in which the evaluators feel free to express their thoughts.
Avoid coaching user on the “right” way to perform some function with the prototype.

If the prototype evaluation led to some user interface design decision or to the selection of specific interaction techniques, record those conclusions and how you arrived at them. (p243)

Look for any conflicts between the SRS and the prototype. (p243)

The biggest risk is that a stakeholder will see a running prototype and conclude that the product is nearly complete. (p243)

Make it clear to those who see the prototype that you will not release it as production software.
One way to control this risk is to user paper, rather than electronic, prototypes.
Use prototyping tools that are different from those used for actual development.
Leaving the prototype looking a bit rough and unpolished also mitigates this risk. (p244)

Another risk of prototyping is that users become fixated on how the user interface will look than how it will operate.
Also, users might expect high level of performance.Consider adding time delays to simulate realistic expected behavior.
Finally, if time is short throwaway prototype may make its way into production code. (p245)

Prototype success factors (p245)

• Include prototyping tasks in your project plan
• Sate the purpose of each prototype before you build it
• Plan to develop multiple prototypes
• Create throwaway prototypes as quickly and cheaply as possible.
• Don’t include extensive input data validations, defensive coding techniques, error-handling code, or code documentation in a throwaway prototype
• Don’t prototype requirements that you understand; prototype what you don’t understand.
• Use plausible data in prototype screen display.Evaluators can be distracted by unrealistic data.

Ch14

Prioritization helps the project manager resolve conflicts, plan for staged deliveries, and make the necessary trade-offs. (p248)

Prioritization is critical for timeboxed or incremental development with tight, immovable release schedules.(p248)
In extreme programming methodology, customers select which user stories they’d like implemented in each two- to three week incremental release, and the developers estimate how many of these stories they can fit into each increment.
Project manager balances schedule, budget, staff and quality goals.

Contributing to requirement prioritization is one of the customer’s responsibilities, which help clarify customer expectation (p249)

Customers and developers both should provide input to requirement prioritization.(p249)

Rapid descoping phase – when nonessential features are jettisoned to ensure that the critical capabilities ship on schedule. (p250)

If left to their own, customers will establish 85% of requirement as high priority, 10% as medium, and 5% as low.If nearly all requirements are truly are of top priority, then the project has a high risk of not being successful. (p250)

Questions to ask in order to determine task priorities (p250):

• Is there some other way to satisfy the need that this requirement addresses
• What would the consequence be of omitting or deferring this requirement
• What would the impact be on the project’s business objective if this requirement weren’t implemented immediately.
• Why would a user be unhappy if this requirement were deferred to a later release

Common prioritization scale groups into three categories of low, medium, and high (regardless of labeling); which is subjective and imprecise.

Use two dimensional matrix for prioritization (p251):

Include the priority of each requirement in the use-case description, the SRS, or the requirement database (p251)

Set priority convention for weather high requirements are result of inheriting low level requirements, or each functional requirement has its own requirement (p251)

With many requirements, choose an appropriate level of abstraction for prioritization – features, use cases, or functional requirements (p252)

You may decide to do an initial prioritization at the feature level and then to prioritize the functional requirements within certain features separately.This will help to distinguish the core functionality from refinements to schedule for later releases.Document even the low-priority requirements. (p252)

Quality Function Deployment (QFD) – a comprehensive method for relating customer value to proposed product features. (p252)

Total Quality Management (TQM) – rates each requirement against several weighted project success criteria and computes a score to rank the priority of the requirements. (p252)

Use a spreadsheet model from http://www.processimpact.com/goodies.shtml
Feature attractiveness is directly proportional to tis cost and the technical risk associated with implementing it.Features with the highest risk-adjusted value/cost ratio should have the highest priority.

Prioritization participants include: project manager, customer representatives, development representative (p253)

During prioritization, keep items in the same level of abstractions.Don’t mix functional requirement with product features.

In your prioritization matrix include driving features (you’ld implement B only if A is implemented)
Group related features together to create manageable initial list.
Have your customers representatives estimate the relative benefit of each feature
Estimate relative penalty that the customer or business would suffer if the feature is excluded
Requirements with low benefit and low penalty add cost but little value; might be gold plating
Developers estimate the relative cost of implementing each feature (1=easy, 9=time consuming)
Rate the relative degree of technical or other risk associated with each feature (1=easy, 9=hard)
Priority = value % / (( cost % * cost weight ) + ( risk % * risk weight ))
(p255-6)

Prioritization questions to ask (p255)

• Would your product suffer in comparison with other products that do contain that capability
• Would there be any legal or contractual consequences
• Violating some government of industry standard
• Would users be unable to perform some necessary or expected functions
• Would it be a lot harder to add that capability later as an enhancement
• Would problems arise because marketing has promised a feature to satisfy some potential customers but the team decided to omit it

Accuracy of prioritization estimate is limited to the team’s ability to estimate benefit, penalty, cost, and risk for each item.Customer and development representatives should review the completed prioritization matrix (p257)

Don’t over interpret small differences in calculated priority numbers.Look for groups of requirements that have similar priority numbers.

Ch15

Research shows that it costs approximately 100 times more to correct a customer-reported requirement defect than to correct an error found during requirement development.Another study found it took 30 minutes to fix an error discovered during the requirement phase, where as it took 5-17 hours to correct a defect during system testing. (p260).

If you start your testing planning and test-case development early, you’ll detect many errors shortly after they’re introduced.This prevents them from doing further damage and reduces your testin and maintenance costs (p260).

Conceptual test case (implementation-independent) based on requirement will reveal errors, ambiguities, and omissions in SRS analysis model long before the team writes any code.
Requirement validation is the fourth component – with elicitation, analysis and specification – of requirements development (p261)

Requirement validation purpose:

• Correctly describe the intended system capabilities for all stakeholders
• Software requirements were correctly derived from the system requirements, business rules, or other sources.
• The requirements are complete and high quality
• All requirements representations are consistent with each other
• Requirements provide an adequate basis to proceed with design and constructions

Some validations activities (like incremental reviews of SRS) are threaded throughout the elicitation, analysis, and specifications processes.Other activities, such as formal SRS inspection, provide final quality gate prior to baseline the SRS.Include requirements validation activities as discrete tasks in your project plan. (p261)

Intuitively, it seems that inserting time into the schedule to improve requirements quality would delay planned ship date; in actuality, the investment can actually shorten the delivery schedule by reducing the rework required and by accelerating system integration and testing
Investing in requirement quality always saves you more money than you spend (p262).

Quantify each requirement so that you can think of a way to measure how well a proposed solution satisfies it (p262).

Peer review occurs when ever someone other than the author reviews the artifact.
Peer review of requirement documents is a powerful technique for identifying ambiguous or unverifiable requirements (p262)

Informal review process includes: peer deskcheck (colleague to look over), pass-around, walkthrough (author describes deliverable and solicits comments).

Formal review produces a report that identifies the material, the reviewers, and the review team’s judgment as to whether the product is acceptable.The principal deliverable is a summary of the defects found and the issues raised. (p263)

If your serous about maximizing software quality, your team will inspect every requirement document it creates. If you don’t have time, use risk analysis to differentiate those requirements that demand inspection.Begin inspections when SRS is only 10% done (263).

Any software work product can be inspected, including requirements, design documents, source code, test documentations, and project plan. (p264)

Inspections provide a quality gate through which documents must pass before they are baselined.

Sample peer review and defect checklist can be found at http://www.prodcessimpact.com/goodies.shtml.

Participants in an inspection should include four representatives: author & peers of the author, people that will interface with the product, group that will work on the item being inspected, author of any predecessor work.Try to limit the team to six or fewer inspectors (p265).

Inspection roles include author, moderator, reader and recorder.
Author of artifact takes more passive role during an inspection.Author may not assume any other role.
Moderator (inspector leader) plans the inspection with the author, coordinates the activities, and facilities the inspection meeting.Moderator distributes material days before inspection meeting and follows up on proposed changes with the author.
Reader paraphrases the SRS in his own words (highlighting potential defects or ambiguity), which provides interpretation that might differ from that held by other inspectors.
Recorder uses standard forms to document the issues raised.He reviews the and reads the conclusions out loud to confirm the record’s accuracy. (p265).

Inspection entry criteria keeps the team from spending time on issues that should have been resolved prior to inspection. (p266)

Inspection entry criteria checklist includes: (p266)

• Document conforms to the standard template
• Document has been spell checked
• Author has examined the document for any layout errors
• Line numbers are printed on the document to facilitate inspection meeting
• All open issues are marked TBD (To be determined)
• The moderator didn’t find more than three major defects in ten minute examination
• Reference or predecessor documents are available for moderator to review

The author and moderator plan the inspections together, who should participate, what materials the inspectors will need, how many inspection meetings.

Two to four pages per hour is a practical guideline (p267).
Maximum defect-detection effectiveness is about half that rate.Adjust rate based on:
Teams previous inspection data, amount of text on each page, specification complexity, risk of undetected errors, the criticalness of artifacts, experience of author of the SRS.

During inspection meeting, author describes the background of the material to be reviewed, and assumptions made.(p268)

Prior to inspection meeting, each inspector examinees the product using a checklist of typical defect.
Up to 75% of defects are found during inspection preparation (p268)

Don’t proceed with inspection meeting if the participants haven’t already examined the work product on their own.Ineffective meetings can lead to the erroneous conclusions that inspections are waste of time (p268)

Ask developers to review the SRS to rate each requirement as to how well they understand on scale of 1 to 5 (p268)

During inspection, reader leads the other inspectors through the SRS, describing one requirement at a time in his own words.Recorder captures the issues that become action items; identifying as much defects as possible in the 2-4 hour meeting (p268)

During meeting conclusion, the team 1) accepts the requirement with minor revisions, or 2) indicate a major revision is needed (may indicate problem with the requirement development process; consider holding a retrospective to explore how the process can be improved). (p269)

Meetings can reveal additional defects that no inspectors found during their individual preparation.Make a risk-based decision as to how much energy to devote to improving requirement quality. (p269)

Moderator insures that the author corrects the errors properly; and determines if the inspections’ exit criteria have been satisfied. (p269)

Possible exit criteria include (p269-270):

• All issues raised during inspections have been addressed
• Changes made in the document & related work products were made correctly
• Check spell the revised document
• All To-Be-Determined (TBD) have been resolved; or each TBD resolution process, target date, and owner has been documented
• Document is checked into project configuration management

Develop a defect checklist for each type of requirement type for you organization.
Pay attention to historical frequent requirement problems.
Ask certain inspectors to use different subset of the overall checklist.
Assigning defect detection responsibility is more effective than handing all inspectors the same checklist.(p270)

Check list (p270-271):

• Is the use case a stand-alone, discrete task
• Is the goal, or measurable value, of the use case clear
• Is it clear which actor or actors benefit from the use case
• Is the use case written at the essential level, free of unnecessary design and implementation details
• Are all anticipated alternative courses documented
• Are all known exceptions conditions documented
• Are there any common action sequences that could be split into separate use cases
• Are the steps for each course clearly written, unambiguous, and completed
• Is each actor and step in the use case pertinent to performing that task
• Is each alternative course defined in the use case feasible and verifiable
• Do the preconditions and postconditions properly frame the use case

Organization and completeness

o Are all internal cross-references to other requirements correct

o Are all requirements written at a consistent and appropriate level of details

o Do the requirements provide an adequate basis for design

o Is the implementation priority of each requirement included

o Are all external hardware, software, and communication interfaces defined

o Are algorithms intrinsic to the functional requirements defined

o Does the SRS include all the known customer or system needs

o Is any necessary information missing from a requirement? If so, is it identified as a TBD?

o Is the expected behavior documented for all anticipated error conditions

Correctness

o Do any requirements conflict with or duplicate other requirements

o Is each requirement written in clear concise, and unambiguous language

o Is each requirement verifiable by testing, demonstrating, review, or analysis

o Is each requirement in scope of the project

o Is each requirement free from content and grammatical errors

o Can all requirements be implemented within known constraints

o Are all specified error messages unique and meaningful

Quality attributes

o Are all performance objectives properly specified

o Are all security and safety considerations properly specified

o Are other pertinent quality attribute goals explicitly documented and quantified, with the acceptable trade-offs specified

Traceability

o Is each requirement uniquely and correctly identified

o Is each software functional requirement traced to a higher-level requirement (for example, system requirement or use cases)

Special issues

o Are all requirements actually requirements, not design or implementation details

o Are time-critical functions identified and their timing criteria specified

o Have internationalization issues been adequately addressed

Asking colleagues to tell you what’s wrong with your work is a learned – not instinctive-behavior (p272)

To avoid overwhelming the inspection teams with a large requirement (several hundred pages), perform incremental reviews.

Identify the high-risk areas that need a careful look, and use informal reviews for less risk material.Ask specific inspectors to start at different locations in the document to make certain that fresh eyes have looked at every page. (p272)

Inspection elements to keep in mind (p273)

• Make sure every participant is there to find defect, not to be educated or protect political reason
• Have only one representative of each perspective (customer, developer, tester)
• Multiple inspection teams find more defects in a requirement than a large inspection team

If you choose not to hold an inspection meeting, recognize that this can reduce the inspection’s effectiveness by perhaps 25 percent, but it also reduces the cost of the inspection

Watch out for tester who claim that they can’t begin their work until the requirements are done and for testers who claim that they don’t need requirements to test the software.Testing and requirements have synergistic relationship because they represent complementary views of they system. (p274)

Writing black box (functional) test cases crystallizes your vision of how the system should behave under certain conditions.Vague and ambiguous requirements will jump out at you because you won’t be able to describe the expected system response.
When analysts, developers, and customers walk through the test cases together, they achieve a shared vision of how the product will work (p274)

Ideally, an analyst write the functional requirements and a tester will write the test cases from a common starting point, the user requirements (p275).

Trace the execution path for every test case on a dialog map with a highlighter pen; thus, you can find incorrect or missing requirements, correct errors in the dialog map, and refine the test cases. (p279)

Analyst and the tester combined requirements, analysis models, and test cases to detect missing, erroneous, or unnecessary requirements long before any code was written.Conceptual testing of software requirements is a powerful technique for controlling a project’s cost and schedule. (p279)

Acceptance criteria - acceptance testing – should evaluate whether the product satisfies its documented requirements.
Having users device acceptance tests is an effective requirements development strategy (p280)
Acceptance tests focus on the normal courses of the use cases, not on the less common alternative courses or whether the system handles every exception condition properly.Automate acceptance tests whenever possible.
Test should also ought to address nonfunctional requirements (p280)

User acceptance testing does not replace comprehensive requirements-based system testing, which cover both normal and exception paths and a wide variety of data combinations. (p280)

Have customers develop acceptance criteria.

During requirement elicitation ask: What do you need to do with the system?How would you judge whether the system satisfies your needs?
Requirement is not satisfactory if customer is unable to satisfactory answer these questions (p280)

Acceptance test planning, informal reviews, SRS inspections, and requirements testing techniques will help to build higher quality systems faster and more inexpensively. (p281)

Ch16
Green-field project – new software or system development project (p283)

Maintenance = continuing engineering = ongoing development – software in operations (p283)

Reverse-engineering = software archaeology (p284)

One useful technique to finding missing information, is to draw a dialog map for the new screens you have to add, showing the navigation connections to and from existing display elements.Other modeling techniques such as class and interaction diagrams, and entity-relationship diagrams are also useful.A context diagram or use-case diagram depicts the external entities.
Another way to begin filing the information void is to create data dictionary entries when you add new data elements (p285).

Including portions of systems within requirement achieve the following

• Halts the knowledge drain
• Collect information that was previous undocumented.The incremental cost of recording newly found knowledge is small

If you have to perform software surgery (i.e. satisfy revised government requirements), begin listing the business rules that affect the system (p285)

When you implement a change, take the time to document what you discovered (p285)

Sometimes it makes sense write SRS for an existing system when it will be used and improved upon in future (p286)

Maintenance projects provide an opportunity to try new requirement engineering methods in a small-scale and low risk way.It’s tempting to claim that a small enhancement doesn’t warrant writing any requirements.Enhancement projects let you tackle the learning curve in bite-sized chunks.Explore the new feature from use-case perspective, discussing with the requester the tasks that users will perform with that feature (p287).

Requirements traceability data will help the maintenance programmer determine which components he might have to modify because of a change in a specific requirement.
Create a partial requirements traceability matrix to link the new or changed requirements to the corresponding design elements, code, and test cases. (p287)

Inspection participants should represent: 1) author of the requirements, 2) representative who can ensure that the new requirements accurately describe the needed change, 3) people whose work product is effected, 4) developer, tester who will do the work (p288)

Obsolete requirements and design documents aren’t helpful; there is widespread fear in the software industry that writing documentation will consume too much time; What’s the cost if you don’t update requirements and a future maintainer has to regenerate that information? (p288)

Requirements can help evaluate the candidates to identify the most appropriate package for your needs (p288)

Evaluate off the shelf products by: (1) rate requirements 1-10, (2) Rate each package how it satisfies requirement between 0 to 1, (3) rate non-function requirement, performance, suability, etc, (4) evaluate cost, vendor viability, support, external interface for extension (p289)

Focus the requirements for COTS acquisition at the user requirements level.There is no need for detailed functional requirements for COTS. (p289)

The use cases permit a gap analysis, so you can see the places where customization or extension will be needed to meet your needs (p290)

Prioritize the use cases and reports.Distinguish capabilities that must be available on day one from those that can wait for future extensions and those that your users can live without.
To determine whether - and how well the package will let the users perform their tasks, derive test cases from the high-priority use cases.Include significant exception conditions.Expand usage patterns (operational profile) (p290)

When evaluating COTS, determine:
1)can it conform to your standards, 2) how easy can it be updated to meet the changes, 3) will the vendor provide new version when regulation change (i.e. tax calc) and how fast, 4) what business rule implements and can you disable any

Define quality requirements for your COTS selection: performance, usability, flexibility (to extend the package), interoperability (integrate with other packages), Integrity (safety)
You need to know which requested capabilities aren’t negotiable and which you can adjust to fit within package constraint (p291)

Demand high quality written requirements for outsourcing
Poorly defined and managed requirements are a common cause of outsourced project failures (p292)

Outsourcing check list (p292-3):

1) provide details

2) avoid ambiguity (words),

3) arrange touch points with the supplier
Peer reviews and prototypes provide insight into how the supplier is interpreting the requirements

4) Define a mutually acceptable change control process.
45% of outsourced projects are risk from creeping user requirements
Contract should specify who will pay for various kinds of changes, such as newly requested functionality or corrections made in the original requirements.

5) plan time for multiple cycles and reviews of requirement.Consider communication delays when dealing with geographical barriers.

6) Define acceptance criteria

Emergent projects are characterized by uncertain requirements and frequent changes.They demand iterative, incremental, and adaptive approaches to both requirements development and software development; in such cases, you may need to base development on vague, and high-level statements of business objectives (p293)

The agile methodologies take a lean approach to requirements.Requirements are described in terms of product features or in the form of user stories, which are similar to the casual use cases described.
Continuous interaction with an on-site customer representative, who supplies the remaining requirement details and answer questions is vital.
To cope with change, systems are built in small increments with the expectation that subsequent increments will modify what already exits.
Iterative development cycle actually encourages requirement change and scope creep.
Stakeholders sometimes claim that the requirements are unknown and unknowable in their desire to dive right into coding, disregarding the potential need for extensive recording. (p294)

Agile methodology – extreme programming – advocates recording requirements in the form of simple user stories written on index card.It demands that the customers understand their requirements (p294)

Every project should represent its requirements in forms that can be shared among the stakeholders, be updated and be managed through the project.Someone needs to be responsible for this documenting and updating. (p295)
A fundamental tenet of extreme programming is the presence of a full time, on-site customer for these discussions. Most projects have multiple user classes, as well as additional stakeholders (p295)

Streamline your change process so that the minimum number of people can make decisions about requested changes as quickly as possible for emerging projects. (p296)

Ch17

Software requirement class training can stress the importance to all stakeholders, share understanding of business objectives and expose all team members to requirement terminology, concepts, and practices. (p297)

As illustrated above, requirements define the project’s intended outcomes. However, the most important project outcome is a system that meets its business objectives, not necessarily the one that implements all the initial requirements according to the original project plan. (p298)

Projects business success will be problematic if you don’t update your plans to align with evolving objectives and realities.

Past small projects used 12-15% for requirements engineering; however, it depends on complexity

In banks, most successful project spent 28% in requirements engineering:

11% requirements elicitation

10% modeling

7% validation and verification

Average project spent 15.7% of effort and 38.6% of schedule to requirements engineering (p299)

Not all requirements development efforts should be allocated to the beginning of the project. First step in project estimation is to assess size of the software project. Base size estimates on:

1. Textual requirements

2. Analysis models

3. Prototypes

4. User interface designs (p300)

Frequently used metrics:

1. Testable requirements

2. Function & feature points

3. Number, type and complexity

4. Lines of code

5. Count of object classes

Estimate variables include developer skill, project complexity, and team experience. Also, estimates need to be compared to actual project results to improve estimating ability.

For frequent changes in scope, project should be deferred until customer needs are clearer. Estimates should be justified based on a well-though-out process and historical data.For schedule conflicts, project’s business objectives should dictate whether to reduce scope, add resources, or compromise on quality. (p301)

Requirements uncertainty is unavoidable early in the project; contingency buffers should be included in schedule and budget. Extensive requirements growth indicates that many requirements were missed during elicitation.

Select appropriate size metrics for projects. Complex, nonlinear relationships exist between product size, effort, development time, productivity, and staff buildup time. (p302)

Right-to-left scheduling: a delivery date is cast in concrete and then the product’s requirements are defined. A design-to-schedule strategy can work, if the project manager can negotiate what portion of the desired functionality can fit within the schedule constraints.

For complex systems where software is only part of the final product, high-level schedules are generally established after developing the product-level (system) requirements and a preliminary architecture. Projects that have uncertain requirements benefit from an incremental development life cycle.

Effective project planning requires the following elements:

1. Estimated product size

2. Productivity of the development team (based on historical performance)

3. List of tasks needed to completely implement and verify a feature or use case

4. Reasonably stable requirements

5. Experience (p303)

Specification should not contain inadvertent design, or needless or unintended restrictions on the final design.Studying a proposed architecture provides a different perspective that helps to verify the requirements and time their precision, as does prototyping.

Architecture is especially critical for systems that include both software and hardware components and for complex software-only systems. An essential requirements analysis step is to allocate the high-level system requirements to the various subsystems and components. (p304)

Allocation of system capabilities to subsystems and components must be done from top down. If you leap directly from requirements into code, you end up designing the whole software on the fly. Although you come up with a design, it is not an excellent design – more likely resulting in poorly structured software. Although refactoring the code can improve the design, an ounce of up-front design is worth a pound of post-release refactoring. (p305)

As with requirements, excellent designs are the result of iteration. Shortcomings in design lead to products that are difficult to maintain and extend and that don’t satisfy the customer’s performance, usability, and reliability objectives.

Although you don’t need t o develop a complete, detailed design for the entire product before you begin implementation, you should design each component before you code it. (p306)

All projects will benefit from:

1. Develop a solid architecture

2. Identify the key object classes or functional modules – defining their interfaces, responsibilities

3. For parallel-processing systems, understand the planned execution threads

4. Define each code unit’s intended functionality, following design principles of strong cohesion, loose coupling and information hiding

5. Ensure design accommodates all functional requirements and does not contain unnecessary functionality

6. Ensure that design accommodates exceptional conditions

7. Ensure that design achieves performance, robustness, reliability

If an issue is not resolved immediately, any assumptions, guesses, or interpretations that a developer makes should be documented and reviewed with customer representatives.

Testing and requirements engineering have a synergistic relationship. Product should be tested against what it was intended to do as recorded in the requirements document, not against design or code. System testing that based on code can become a self-fulfilling prophecy. (p307)

Requirements are the ultimate reference for system and user acceptance testing. Analyst should incorporate the legitimate implied requirements and their origins into the SRS to make future testing more effective.

Project tester methods include:

1. Testing

2. Inspection

3. Demonstration

4. Analysis

Analytical techniques should be used to derive test bases based on the logic described in the requirement. This reveals ambiguities. Every functional requirement should trace to at least one test case. Measure testing progress by tracking percentage of the requirements that have passed their tests. (p308)

Specification-based testing applies several test design strategies: action driven, data-driven, logic-driven and state-driven. It is possible to generate test cases automatically. Testing against requirements must be performed at every level of software construction, not just the end-user level. Much of the code in an application isn’t directly accessed by users but is needed for infrastructure operations. Testing the system against user requirements is a necessary strategy for system testing.

The prospect of trying to understand a huge volume of even excellent requirements is certainly daunting, but ignoring them is a decisive step toward project failure. A requirement that didn’t’ satisfy its test criteria was counted as an error. (p309)

Without a project plan, software designs and system tests on a foundation of high-quality requirements. (p310)

Ch18

Requirement management activities include (p314):

1. Change control:Proposing changes, analyzing impact, Making decisions, updating requirements document, updating plans, measuring requirement volatility
2. Version control: defining a version identification scheme, identifying requirements document version, identifying individual requirement version
3. Requirements status tracking: Defining possible requirement statuses, recording the status of each requirement, reporting the status distribution of all requirements
4. Requirements tracing: Defining links to other requirements, defining links to other system elements

You can respond to requirement changes by: staff, schedule, quality, overtime, reprioritize (p314)

Requirement baseline is the set of functional and nonfunctional requirements that the development team has committed to implement in a specific release; which is set under configuration management. Subsequent changes can only be made through the project’s defined change control process. (p315)

Document methods for (p316) :

• Versioning and version control
• Methods for Baselineing
• Status and change updates (who will do them)
• Requirement status-tracking procedure
• Change process control (how requirement changes are proposed, processed, negotiated, communicated)
• How to analyze the impact of the proposed change
• How the project plan and commitments will reflect requirement change

Ensure that someone owns the requirement management activities.Project’s requirement analyst typically has the lead responsibility for requirements management.
If NO ONE on the project has responsibility for performing requirements management activities, then don’t expect them to get done. (p316)

Requirement management includes: Storage, requirement attributes, coordination (status, updates, tractability), reports, change activities.

To minimize confusion, conflict, and miscommunication, permit only designated individuals to update the requirements, and make sure that the version identifier changes whenever a requirement changes (p317).

Consider appending a version number to each indiviudal requirement label, which you can increment whenever the requirement is modified, such as Print.Confirmatio-Copies-1 (p318)

When you baseline a document marked up (i.e. word version tracking), first archive a marked-up version, then accept all the revisions, and then store the now-clean version as the new baseline file, ready for the next round of changes; thus, you can always trace the source and rational for changes. (p318)

Requirement attributes establish a context and background for each requirement that goes well beyond the description of intended functionality (p319).

Consider specifying the following requirements attributes:
created, version, author, reviewer, owner/stakeholder, status, requirement source, reason for requirement, allocated subsystem, product release version, verification method, priority of implementation, stability (change) p319.

An example of requirement reason can be: because it is in competitor’s product (p320)

Avoid spending time dragging requirement from one SRS to another.One way to handle this is to store the requirements in a requirements management took, and define a release number attribute.Simply updating the release number shifts the requirement into a different baseline.
Rejected requirements are best handled using requirement status attribute .

Defining and updating requirement attributes is part of the cost of requirement management, but that investment can yield a significant payback. (p321)

Tracking the status of each functional requirement throughout development provides a more accurate gauge of project progress (p321).

Some practitioners add the Status Designed (design elements that address functional requirements have been created and reviewed) and Delivered (handed to user, beta testing).
Keep a record of reject requirements and the reasons they were rejected, because dismissed requirements have a way of resurfacing (p322).

Classifying reuqirements into several status categories is more meaningful than trying to monitor the precent completion of each requirement (p322)

Certain status changes also lead to updating requirements traceability data to indicate which design, code, and test elements addressed the requirements (p322)

Suggested requirement status (322-3):

• Proposed – requested by authorized user
• Approved – requirement is analyzed, its impact assessed, baselined, stakeholders informed.
• Implemented – code has bee designed, written, unit tested.
• Verified – confirmed in the integrated product; requirement is traced to the test case; requirement is considered complete.
• Deleted – Removed from base line (why, and by who)
• Rejected – explain why and by whom

A body of work is done when all the allocated requirements have a status of either Verified (implemented as intended) or Deleted (removed from baseline)

Track how much effort you spend on requirements management; thus, you can evaluate whether that was too little, about right, or too much and adjust your processes and future planning accordingly (p324).

Measuring actual development and project management effort requires a culture change, and individual discipline to record daily work activity

Note that work effort is not same as elapsed calendar time.

Total effort for a task, in units of labor hours, doesn’t necessarily change, but duration increases. (p324)

Failing to manage requirements increases the project’s risk from controlled changes (p324)

Requirement activities to track:

• Submitting requirement changes
• Evaluating proposed changes
• Change control board activity
• Communicating requirements to stakeholders
• Tracking and reporting requirements status
• Collecting requirements traceability information

Effective requirement management can reduce the expectation gap by keeping all project stakeholders informed (p324)

Ch 19
Developers who want to be accommodating by agreeing to added enhancements through the back door instead of being approved by stakeholders risk schedule slips and quality problems. (p327)

Organizations serious about managing its software projects must ensure that:

· Proposed requirements changes are carefully evaluated

· Appropriate individuals make informed business decisions

· Approved changes are communicated to all participants

· Project incorporates requirements changes in a consistent fashion

Software change isn’t a bad thing. Even rejected change request consumes the resources needed to submit, evaluate, and decide to reject it. The closer you get to the release date, the more you should resist changing that release because the consequences of making changes become more severe. If a change is needed to be made, start at the highest level of abstraction that the change touches and cascade the impact of the change through the related systems components. (p328)

Late changes have an big impact on work already performed. A small modification here, an unexpected enhancement there, and soon the project has no hope of delivering what the customers expect on schedule and with the acceptable quality.

The first step in managing scope creep is to document the vision, scope and limitations of the new system as part of the business requirements. Next, evaluate every proposed requirement or feature against the business objectives, product vision, and project scope. (p329)

Prototyping is an effective technique for controlling scope creep. Prototype provides a preview of possible implementation. Using short development cycles to release a system incrementally provides frequent opportunities for adjustments when requirements are highly uncertain or rapidly changing. Also, using words such as “not now” is more palatable than a simple rejection. Customers aren’t always right, but they do always have a point. Stifling change prematurely ignores the realities that customers aren’t always sure what they need. (p330)

Change-control process lets you track that status of all proposed changes and helps ensure that suggested changes aren’t lost of overlooked. It’s a funneling and filtering mechanism to ensure that the project incorporates the most appropriate changes.

If you ask stakeholders to follow a new change-control process that ineffective, cumbersome, or too complicated, people will find ways to bypass the process. (p331)

Helpful change-control policy statements: (Change-Control Policy Guideline)

· All requirements changes shall follow the process. If the process isn’t followed, the proposed change will not be considered.

· No design or implementation work other than feasibility exploration shall be performed on unapproved changes.

· Simply requesting a change doesn’t guarantee that it will be made. Projects change control board will decide which changes to implement.

· Contents of the change database will be visible to all project stakeholders

· Original text of a change request shall not be modified or deleted

· Impact analysis shall be performed for every change

· Every incorporated requirement change shall be traceable to an approved change request

· Rationale behind every approval or rejection of a change request shall be recorded.

No change affecting more than one individual’s work should bypass your change-control process. Process should include a “fast path” to expedite low-risk, low-investment change requests in a compressed decision cycle. (p332)

Download a sample change-control process description from processimpact.com

Four components in all procedures and process descriptions:

· Entry criteria: Condition that must be satisfied before executing the process or procedure

· Various tasks involved; project role responsible for each task

· Steps to verify that the tasks were completed correctly

· Exit Criteria (p333)

Change-Control Process

1. Introduction: Provides purpose, scope and definitions.

2. Roles and Responsibilities: list the project team members by role, not name.

3. Change request status – defined life cycle of proposed change (p334)

4. Entry Criteria – Assign a unique identification tag to every change request and route them all to a single point of contact, the request receiver (p335)

5. Tasks – evaluate request for technical feasibility, cost and alignment with the project’s business requirements; perform impact analysis, risk analysis, hazard analysis, or other assessments

6. Verification – requirements changes are typically verified through a peer review and use traceability information; verification of changes made in downstream work products through testing or review.

7. Exit Criteria: status of request is rejected, closed or canceled; modified products are installed into the correct locations; CCB or other relevant project participants are notified of the change details; requirements traceability matrix has been updated (p336)

8. Change-control status reporting – charts typically show the number of change requests in each status category as a function of time and describe the procedures for producing the charts and reports.

Appendix: Suggested Change-Request Data Items

· Change origin: Functional area that requested the change

· Change-request ID: identification tag or sequence number assigned to the request

· Change type: type of change request such as requirement change, proposed enhancement, or defect report

· Date Submitted: date originator submitted change request

· Date updated: date change request was most recently updated

· Description: free-form text description of the change being requested

· Implementation priority: relative importance of making the change as determined by the CCB

· Modifier: individual primarily responsible for implementing the change

· Originator: individual who submitted change request

· Originator priority: relative importance of making change from the originator’s point of view

· Planned release: product release or build number for which an approved change is scheduled

· Project: name of project in which a change is being requested

· Response: free-form text of responses made to change requests

· Status: current status of the change request

· Title: one-line summary of proposed change

· Verifier: individual who is responsible for determining if change was made correctly (p337)

Change Control Board (CCB) has been identified as a best practice for software development. A CCB reviews and approves changes to any baseline work. Large projects or programs might have several levels of CCBs. An effective CCB will consider all proposed changes promptly and will make timely decisions. (p338)

CCB membership should represent all groups who need to participate in making decisions. To ensure that the CCB has adequate technical and business information, invite other individuals to a CCB meeting when specific proposals are being discussed that relate to those individuals’ expertise.

CCB charter describes the propose, score of authority, membership, operating procedures, and decision-making process. A template for a CCB charter is available from processimpact.com (p339).

Charter should state the frequency of regularly scheduled CCB meetings and the conditions that trigger a special meeting. Scope of the CCB’s authority indicates which decisions it can make and which ones it must pass on to a high-level CCB or a manager.

Decision-making process description should indicate the following:

· Number of CCB members or the key roles that constitutes a quorum for making decisions

· Whether voting, consensus, consultative decision making, or some other decision rule is used

· Whether the CCB chair may overrule the CCB’s collective design

· Whether the higher level of CCB or someone else must ratify the decision

CCB balances the anticipated benefits against the estimated impact of accepting a proposed change. If the estimated cost or schedule impact exceeds the established thresholds for this level of CCB, refer the change to management or to a higher-level CCB. (p340)

Before accepting a significant requirement change, renegotiate commitments with management and customers to accommodate the change.

Change-control tools help the change-control process operate more efficiently. Look for the following features in a tool:

· Define the data items included in a change request

· Define a state-transition model

· Enforces the state-transition model so that only authorized users can make permitted status changes

· Records identity and date of every status change

· Defines who receives automatic email notifications

· Produces both standard and custom reports and charts (p341)

Measuring change activity should be motivated by the questions you or your managers are trying to answer and should be used to assess the stability of the requirements.

Track the following aspects of requirements change activities:

· Number of change requests received, currently open and closed

· Cumulative number of changes made

· Number of change requests that originated from each source

· Number of changes proposed and made in each requirement since it was baselined

· Total effort devoted to processing and implementing change requests

· Number of cycles through the change process that it took to correctly implement each approved change (p342)

However, don’t count changes before baselining. Once you’ve baselined requirements, all proposed changes should follow your change-control process. Also begin to track the frequency of change (requirements volatility). This change frequency chart should trend toward zero as the project approaches its ship date. A sustained high frequency of changes implies a risk of failing to meet your schedule commitments. It also indicates that the original baselined requirements were incomplete. (p343)

Impact analysis is a key aspect of responsible requirements management. The analysis examines the proposed change to identify components that might have to be created, modified, or discarded and to estimate the effort associated with implementing the change.

Impact Analysis Procedure has three aspects:

1. Understand the possible implications of making the change.

2. Identify all the files, models, and documents that might have to be modified

3. Identify the tasks required to implement the change, and estimate the effort needed to complete those tasks. (p345)

Many estimation problems arise because the estimator doesn’t think of all the work required to complete an activity. Therefore, this impact analysis approach emphasizes comprehensive task identification. For substantial changes, use a small team, not just one developer. (p347)

Ch 20

Change impactanalysis is easier if you have a road map that shows where each requirement or business rule was implemented in the software. (p353)

Traceability links allow you to follow the life of a requirement both forward and backward, from origin through implementation. To permit traceability, each requirement must be uniquely and persistently labeled so that you can refer to it unambiguously throughout the project.(p354)

If testing results something not in requirements, then requirements need to be updated, or it is an instance of gold planting. Traceability links can help you sort out these kinds of situations and build a more complete picture of how the pieces of your system fit together. They also help you keep track of parentage, interconnections, and dependencies among individual requirements. In some instances, you only need to trace system tests back to functional requirements or use cases. (p355)

Requirements tracing provides a way to demonstrate compliance with a contract, specification or regulation. It can improve the quality of your products, reduce maintenance costs, and facilitate reuse. However, tracing requirements is a manually intensive task that requires organizational commitment. One of the benefits of implementing requirements traceability is for maintenance. A table that shows where each applicable business rule was implemented in the functional requirements, designs, and code makes it easier to make the necessary changes properly.(p357)

Although difficult to quantify, the investment will pay dividends anytime you have to modify, extend, or replace the product. Defining traceability links is not much work if you collect the information as development proceeds. (p358)

Fill in the information as the work gets done, not as it gets planned. For example, only when the code in the function has been written, has passed its unit tests, and has been integrated into the source code baseline for the product should it be added to the traceability matrix. This way, individuals know that populated cells in the requirements traceability matrix indicate work that’s been completed. (p359)

Another way to represent traceability information is through a set of matrices that define links between pairs of system elements, such as:

· Requirement to other requirements of that same type

· Requirement to requirement of another type

· Requirement to test cases.

The matrices above can be used to define various relationships that are possible. (p361)

For those individuals who are required to supply each type of traceability information for your project, explain to them what requirements tracing is, why it adds value, and why they’re being asked to contribute to the process. Gathering and managing requirements traceability date must be made the explicit responsibility of certain individuals or it won’t happen. (p362)

It’s impossible to perform requirements tracking manually for any but very small applications. You can use a spreadsheet to maintain traceability data for up to a couple hundred requirements, however, larger systems demand a more robust system. Requirements tracking can’t be fully automated since the knowledge of the links originates in the development team member’s minds. (p363)

Consider the following sequence of steps when you begin to implement requirements traceability on a specific project:

1. Select the link relationships you want to define

2. Choose the type of traceability matrix you want to use

3. Identify the parts of the product for which you want to maintain traceability information. Start with the critical core functions and the high-risk portions.

4. Modify your development procedures and checklists to remind developers to update the links after implementing a requirement or an approved change.

5. Define the tagging conventions so that they can be linked together. Write scripts that will parse the system files to construct and update the traceability matrices.

6. Identify the individuals who will supply each type of link information and the individual who will coordinate the traceability activities and manage the data

7. Educate the team about the concepts and importance of requirements tracing

8. Have each participant provide the requested traceability information as they complete small bodies of work

9. Audit the traceability information periodically. If a requirement is reported as implemented and verified yet its traceability data is incomplete or inaccurate, your requirements tracing process isn’t working. (p364)

The next time any enhancements or modifications are made, write down what is discovered about connections between code, tests, designs and requirements. (p365)

Ch 21
Avoid the temptation to develop your own requirements management tool (p368)
There are many benefits of using a requirements management tool such as:

· Manage versions and changes

· Store requirements and attributes (using a release number attribute) (p370)

· Facilitate impact analysis (trace each functional requirement back to its origin or parent so that you know where every requirement came from)

· Track requirements status

· Control access

· Communicate with stakeholders

· Reuse requirements (p371)

Consider how you would publish a baseline set of requirements into a version control tool and how you would define traceability links between functional requirements and specific design or code elements. Also, don’t base a project’s success on a tool you’re using for the first time. Gain some experience working with the tool on a pilot project before you employ it on a high-stakes project.(p374)

Buying a tool is easy; changing your corporate culture and processes to accept the tool and take best advantage of it is much harder. (p375)

Consider the following cultural and process issues as you strive to maximize your return on investment form a commercial requirements management tool:

· Don’t even pilot the use of a tool until your organization can create a reasonable software requirements specification on paper

· Don’t try to capture requirements directly in the tool during the early elicitation workshops

· Use the tool asgroupware support aid to facilitate communication with project stakeholders

· Think carefully about the various requirement types that you define (p376)

· Define an owner for each requirement type, who will have the primary responsibility for managing the database contents of that type

· Use business, not IT, terminology when defining new data fields or requirements attributes

· Don’t define traceability links until all the requirements stabilize

· Set a date after which the tool’s database will be regarded as the definite repository of the projects requirements

· Instead of expecting to freeze the requirements early in the project, get in the habit of baselining a set of requirements for a particular release.(p377)

For the smoothest transition for making requirements management tools work for you, assign a tool advocate, or a local enthusiast who learns the tool’s ins and outs, mentors other users, and sees that it gets employed as intended. Begin with a pilot application and remember that a tool can’t overcome process deficiencies. Once you’ve made a requirements database work for you, you’ll never go back to plain paper. (p 378)

Ch 22

Requirement documentation has a relationship with (p382):

· Project Planning Process

· Project Tracking and Control Process

· Change Control Process

· System Testing Process

· Construction process of software

· User documentation process

Project planning process can lead to reductions in the project scope or to the selection of an incremental or staged-release approach to deliver functionality in phases. Project tracking and control includes monitoring the status of each requirement. For change control, after a set of requirements have been baselined, all subsequent changes should be made through a defined change-control process. This process helps ensure that:

· The impact of a proposed change is understood

· The appropriate people make informed decisions to accept changes

· All people who are affected by a change are made aware of it

· Resources and commitments are adjusted as needed

· The requirements documentation is kept current and accurate (p383)

Explain to your contact people in each functional area the information and contributions you need from them if the product development effort is to succeed. Agree on the form and content of keep communication interfaces between development and other functional areas such as a system requirements specification or a market requirements document. (p384)

Ask the other organizations what they need form the development group to make their jobs easier. To reduce the fear, communicate your process improvement rationale and intentions to your counterparts in other areas. When seeking collaboration on process improvement, begin from this viewpoint? “here are the problems we’ve all experienced. We think that these process changes will help solve those problems.” Some forms of resistance that you might encounter are:

· A change-control process might be viewed as a barrier, although in reality it is a structure, not a barrier. However, the software team is responsible for ensuring that the change process really does work

· Developers view writing and reviewing requirements documents as bureaucratic – however, by explaining the high cost of continually rewriting the code while the team tries to figure out whatthe system should do, developers and managers will better appreciate the need for good requirements

· If customer-support costs aren’t linked to the development process, development team might not be motivated to change how they work because they don’t suffer the consequences of poor product quality. (p385)

· If one objective of improved requirements processes is to reduce support costs by creating higher-quality products, the support manager might feel threatened.

· Busy customers claim they do no have time to spend working on requirements. Remind them of earlier projects that delivered unsatisfactory systems and the high cost of responding to customer input after delivery.

Four principles of software process improvement:

1. Process improvement should be evolutionary, continuous and cyclical: Instead of aiming for perfection, develop a few improved templates and procedures and get started with implementation.

2. People and organizations change only when they have an incentive to do so. (p386)
Some of the drivers for change procedures are:

a. Project missed deadlines because requirements were more extensive and complicated than expected

b. Developers worked a lot of overtime because misunderstood or ambiguous requirements were addressed late in development

c. System test effort was wasted because the testers didn’t understand what the product was supposed to do

d. The right functionality was present, but users were dissatisfied because of sluggish performance, poor usability, or other quality shortcomings

e. Organization experienced high maintenance costs because customers requested many enhancements that should have been identified during requirements elicitation.

f. Development organization acquired a reputation for delivering software that customers don’t want.

3. Process changes should be goal-oriented: a roadmap that defines pathways to your business objectives greatly improves your chances of successful process improvement.

4. Treat your improvement activities as miniprojects.(p387)

All team members have the opportunity – and the responsibility – to actively improve how they do their work. However, a broad process improvement effort can succeed only if management is motivated to commit resources, set expectations, and hold team members accountable for their contributions to the change initiative.(p388)

The process improvement cycle reflects the importance of knowing where you are before you take off for someplace else, the need to chart your course, and the value of learning from your experiences as part of a continuous process improvement. Step one of any improvement activity is to access the practices currently being used in an organization and to identify their strengths and shortcomings. (p389)

Step two involves planning improvement actions. Each action plan should state the goals of the improvement activities. Include no more than ten items in each action plan. Assign each action item to a specific individual owner who is responsible for seeing that the team is completed. Don’t assign “the team” as an action item owner. Teams don’t do work; individuals do. (p391)

Step three involves creating, piloting and implementing new processes. Many approaches that seem like a good idea in the abstract turn out to be less pragmatic or less effective than anticipated. Plan a process pilot for most new procedures. Keep the following suggestions in mind for the process pilots you conduct:

· Select pilot participants who will give the new approaches a fair try and provide helpful feedback

· Make the outcome easy to interpret, quantify the criteria the team will use to evaluate the pilot

· Identify the stakeholders who need to be kept informed of what the pilot is about and why it is being performed

· Consider piloting portions of the new process on different projects

· As part of the evaluation,ask pilot participants how they would feel if they had to go back to their former ways of working.

Step four involves evaluating results. Asses how smoothly the pilots ran and how effective they were in resolving the uncertainties about the new process. (p393)

Give the new approaches adequate time to work, and select measures that will demonstrate the success of each process change. Also accept the reality of the learning curve – that is, the productivity drop that takes place as practitioners take time to assimilate new ways of working. (p394)

High performance projects have effective processes for all of the requirements engineering components; elicitation, analysis, specification, validation, and management. To facilitate the performance of these processes, every organization needs a collection of process assets. A process encompasses the actions you take and the deliverables you product; process assets help the team members perform processes consistently and effectively. (p395)

Requirement development process assets describe how to identify stakeholders, user classes and product champions in your domain. (p 396)

Allocating high-level product requirements to specific subsystems is necessary. Allocation takes place after the system-level requirements are specified and the system architecture has been defined. To sensibly reduce scope, a requirements prioritization procedure should be followed. The software requirement specification template provides a structured, consistent way to organize the products functional and nonfunctional requirements. Consider adopting more than one template to accommodate the different types or sizes of projects your organization undertakes. This can reduce the frustration that arises when a “one size fits all” template or procedure isn’t suitable for your project. (p397)

The requirements management process describes the actions a project team takes to deal with changes, distinguish versions of the requirements documentation, track and report on requirements status, and accumulate traceability information. It also describes the steps required to approve the SRS and establish the requirements baseline.

The change-control process can reduce the chaos inflicted by endless, uncontrolled requirement changes.(p398)

Estimating the cost and other impacts of a proposed requirement change is a key step in determining whether to approve the change. An accompanying worksheet provides a simple way to estimate the labor for the tasks.

The requirements traceability matrix lists all the functional requirements, the design components and code modules that address each requirement, and the test cases that verify its correct implementation. The traceability matrix should also identify the parent system requirement, use case, business rule, or other source form which each functional requirement was derived. Rather than just diving in, develop a road map for implementing improved requirements practices in your organization (p399)

Ch 23

Typicalrequirements risks include misunderstanding the requirements, inadequate user involvement, uncertain or changing project scope and objectives, and continually changing requirements. (p402)

Project management is fraught with risks caused by poor estimation, rejection of accurate estimates by managers, insufficient visibility into project status, and staff turnover. (p403)

Risk prioritization helps you focus on the most severe risks by assessing the potential risk exposure form each. Risk exposure is a function of both the probability of incurring a loss due to the risk and the potential magnitude of that loss. Risk avoidance is one way to deal with a risk: don’t’ do the risky thing. Risk management planning produces a plan for dealing with each significant risk, including mitigation approaches, contingency plans, owners and timelines. Risk resolution involves executing the plans and finally track your progress toward resolving each risk item through risk monitoring, which should become part of your routine project status tracking. Also, monitor how well your risk mitigation actions are working. Lastly, keep the risk list as a stand-alone document so that it’s easy to update throughout the project’s duration. (p404)

Sample risk item tracking template (p405):

Use a condition-consequence format when you document risk statements. State the risk condition that you are concerned about, followed by the potential adverse outcome, or the consequence from that condition. Often, people who suggest risks state only the condition or the consequence. Pull these statements together in to the condition-consequence structure. Don’t try to quantify risks to precisely. Your goal is to differentiate the most threatening risks from those you don’t need to tackle immediately. You might find it easier simply to estimate both probability and impact as high, medium, or low. (p405)

Assign every risk that you’re going to control to an individual owner, and set a target date for completing that mitigation action. (p406)

A large project should write a separate risk managemet plan that spells out the approach it intends to take to identify, evaluate, document and track risks. Don’t assume that risks are under control just because you identified them and selected mitigation actions. Follow through on the risk management actions. Include enough time for risk management in the project schedule so that you don’t waste your investment in risk planning. Include risk mitigation activities, risk status reporting, and updating of the risk list in our projects task list.

Establish a rhythm of periodic risk monitoring. Keep the ten or so risks that have the highest risk exposure highly visible and track the effectiveness of your mitigation approaches regularly.A risk is not necessarily under control simply because the mitigation actions have been completed. You need to judge whether your mitigation approaches have reduced the exposure. (p407)

Scope creep is more likely if the stakeholders lack a clear, shared understanding of what the product is supposed to be and do. Early in the project, write a vision and scope document that contains your business requirements.A rough guideline is to spend about 10 to 15 percent of your project effort on requirements development activities. (p408)

Devise specific usage scenarios, write test cases from the requirements, and customers develop their acceptance criteria Create prototypes to make the requirements more meaningful for users to elicit specific feedback from them. Query customers about quality characteristics such as performance, usability, integrity and reliability. Determine who the primary customers are. Identify any assumptions the customers might be making. Use open-ended questions to encourage customers to share more of their thoughts, wishes, ideas, information, and concerns that you might otherwise hear. Reverse engineering is an inefficient and incomplete way to discover requirements and no one should be surprised if the new system has some of the same shortcomings as the legacy system. (p409)

Analyst must drill down to understand the intent behind a solution the customer has presented. Evaluate the feasibility of each requirement to identify those that might take longer than anticipated to implement. Don’t underestimate the learning curve of getting up to speed with new techniques that are needed to satisfy certain requirements. Identify those high-risk requirements early on, and allow sufficient time for false starts, learning, experimentation and prototyping.Formal inspections of requirements documents by teams that include developers, testers, and customers can mitigate this risk. Models and prototypes that represent the requirements form multiple perspectives will also reveal fuzzy, ambiguous requirements. (p410)

Designs that are included in the SRS place unnecessary constraints on the options available to developers. Review the requirements to make sure they emphasize what needs to be done to solve the business problem, rather than stating how it will be solved. Also, perform incremental, informal reviews to find problems as early and cheaply as possible. Invite an experienced inspector from your organization or an outside consultant to observe, and perhaps to moderate, your early inspections to coach the participants. (p411)

A requirements change process that includes impact analysis of proposed changes, a change control board to make decisions, and a tool to support the defined procedure is an important starting point. The requirements traceability matrix helps to avoid overlooking any requirements during design, construction, or testing. (p412)