specification development process

ricercare su user stories e cocumber(BDD for testing)

REQUIREMENTS checklist

  • Contesto: Il tema (il titolo) del problema è stato definito chiaramente e riflette i contenuti? Il soggetto è rilevante per gli obiettivi dell'organizzazione? C'è qualche altro motivo per lavorare su questo problema (ad esempio per motivi di studio)?
  • Situazione attuale e dichiarazione del problema: La situazione attuale è chiara e definita logicamente in maniera visuale? Come potrebbe essere definita meglio la situazione attuale per renderla ancora più chiara ai lettori? La definizione della situazione attuale rappresenta il problema o situazione da risolvere? Quale è il problema vero nella situazione attuale? I fatti sono chiari o sono solo osservazioni ed opinioni? Il problema è quantificato in qualche maniera o è qualitativo?
  • Dichiarazione dell'obiettivo: E' stato definito un obiettivo chiaro? Cosa, in particolare, deve essere raggiunto? Come sarà misurato o valutato l'obiettivo? Che cosa dovrà migliorare, di quanto, e quando?
  • Analisi delle cause: L'analisi è comprensibile a livello generico? L'analisi è abbastanza dettagliata e profonda per capire le cause all'origine del problema? C'è l'evidenza dell'analisi delle 5 perché riguardo la vera causa? Il legame tra la causa ed effetto è dimostrabile in qualche modo? Tutti i fattori rilevanti (uomo, macchine, materiali, metodi, ambiente, misure ecc.) sono stati considerati?
  • Contromisure: I passi chiari per l'applicazione delle contromisure sono stati identificati? Le contromisure sono collegate alla causa all'origine del problema? Le contromisure sono rivolte sulle aree giuste di intervento? Chi è responsabile per fare cosa, entro quando? Le azioni definite prevengono la ripetizione del problema in futuro? L'ordine di implementazione delle contromisure è chiaro e ragionevole? Come saranno verificati gli effetti delle contromisure?
  • Controllo e conferma degli effetti: Come sarà misurata l'efficienza delle contromisure? La verifica è allineata con la precedente dichiarazione dell'obiettivo? La prestazione attuale si è mossa in linea con la dichiarazione dell'obiettivo? Se la prestazione non è migliorata, allora perché e cosa non è stato considerato o è mancato?

Azioni successive: Cosa è necessario fare per prevenire la ripetizione del problema in futuro? Cosa ancora rimane da fare? Quali altre parti dell'organizzazione devono essere informate di questi risultati? Come sarà standardizzata e comunicata la nuova procedura?

many tipes of requirements

Business requirements

obiettivi economici del committente. perché fare il sistema? risultati che si spera di ottenere Defining the project scope is the first step in controlling the common problem of scope creep.

User requirements

describe user goals or tasks that the users must be able to perform with the product. described with use cases and event-response tables. An example of a use case is "Make a Reservation" using an airline, a rental car, or a hotel Web site. === Functional requirements === specify the software functionality that the developers must build into the product to enable users to accomplish their tasks

expressed in "shall" statements: "The system shall e-mail a reservation confirmation to the user."

System requirements

a product that contains multiple subsystems, can be all software or it can include both software and hardware subsystems. People are a part of a system, too, so certain system functions might be allocated to human beings.

do not include design or implementation details (other than known constraints), project planning information, or testing information

Bad Requirements means

  • Rework can consume 30 to 50 percent of your total development cost (Boehm and Papaccio 1988), and requirements errors account for 70 to 85 percent of the rework cost (Leffingwell 1997)
  • unnecessary features
  • estimates are inaccurate
  • planning is innacurate
  • scope creep
  • testing is difficult/impossible

symptoms of bad requirements

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

Good Requirement Statement Characteristics

Complete

It must contain all the information necessary for the developer to design and implement that bit of functionality. review them with developes.

Correct

Each requirement must accurately describe the functionality to be built. Only user representatives can determine the correctness of user requirements, which is why real users must review the requirements.

Feasible

It must be possible to implement each requirement. when in doubt/Risk prototypes are ways to evaluate requirement feasibility.

Necessary

Each requirement should document a capability that the customers really need and can generate value. Every requirement should originate from a source that has the authority to specify requirements. Trace each requirement back to specific voice-of-the-customer input, or business rule.

Prioritized

Assign an implementation priority to each functional requirement If all the requirements are considered equally important, it's possible to loose value.

Unambiguous

All readers of a requirement statement should arrive at a single, consistent interpretation of it. review them.

Verifiable

If determining whether it was correctly implemented becomes a matter of opinion, not objective mesure, it's possible to make mistakes.

Good Requirements Specification Characteristics

Sets of requirements should be

Complete

missing requirements: Focusing on user tasks, rather than on system functions, can help you to prevent incompleteness.

Consistent

duplicated requirements: You might not know which single requirement (if any) is correct until you do some research. Recording the originator of each requirement lets you know who to talk to. Each requirement should appear only once in the SRS.

Modifiable

You must be able to revise the SRS when necessary and to maintain a history of changes made to each requirement. This dictates that each requirement be uniquely labeled and expressed separately from other requirements so that you can refer to it unambiguously.

Traceable

design elements, source code, test cases that verify the implementation as correct should trace to corresponding requirements, that's why they are uniquely labeled with persistent identifiers.

Steps

  1. Identifying the product's expected user classes
  2. Eliciting needs from individuals who represent each user class
  3. Understanding user tasks and goals and the business objectives with which those tasks align
  4. Analyzing the information received from users to distinguish their task goals from functional requirements, nonfunctional requirements, business rules, suggested solutions, and extraneous information
  5. Allocating portions of the top-level requirements to software components defined in the system architecture
  6. Understanding the relative importance of quality attributes
  7. Negotiating implementation priorities
  8. Translating the collected user needs into written requirements specifications and models
  9. Reviewing the documented requirements to ensure a common understanding of the users' stated requirements and to correct any problems before the development group accepts them
  10. Approving requirements: agreement that what is on the specification is what estimate and plans are based on.

The Customer-Development Partnership

Excellent software products are the result of a well-executed design based on excellent requirements. High-quality requirements result from effective communication and collaboration between developers and customers: partnership. Too often, the relationship between development and customers becomes adversarial.

Software Customers have the right to

  1. Expect analysts to speak your language
  2. Expect analysts to learn about your business and your objectives for the system
  3. Expect analysts to structure the information you present during requirements elicitation into a written software requirements specification
  4. Have analysts explain all work products created from the requirements process
  5. Have analysts and developers provide ideas and alternatives both for your requirements and for implementation of the product
  6. Describe characteristics of the product that will make it easy and enjoyable to use
  7. Be given opportunities to adjust your requirements to permit reuse of existing software components
  8. Receive good-faith estimates of the costs, impacts, and trade-offs when you request a change in the requirements
  9. Receive a system that meets your functional and quality needs, to the extent that those needs have been communicated to the developers and agreed upon

Software Customers You have the responsibility to

  1. Educate analysts and developers about your business and define business jargon
  2. Spend the time that it takes to provide requirements, clarify them, and iteratively flesh them out
  3. Be specific and precise when providing input about the system's requirements
  4. Make timely decisions about requirements when requested to do so
  5. Respect a developer's assessment of the cost and feasibility of requirements
  6. In collaboration with the developers, set priorities for functional requirements, system features, or use cases.
  7. Review requirements documents and evaluate prototypes
  8. Communicate changes to the requirements as soon as you know about them
  9. Follow the development organization's process for requesting requirements changes and engineering

Approving the requirements

Approving the requirements brings closure to the requirements development process. However, agree on precisely what they're saying with their signatures. Don't use sign-off as a weapon. Use it as a project milestone, with a clear, shared understanding of the activities that lead to sign-off and its implications for future changes.

"I agree that this document represents our best understanding of the requirements for this project today and that the system described will satisfy our needs. I agree to make future changes in this baseline through the project's defined change process. I realize that approved changes might require us to renegotiate the cost, resource, and schedule commitments for this project."

Requirements Management

establishing and maintaining an agreement with the customer on the requirements for the software project. communicate progress in value delivering.

  1. Defining the requirements baseline (a snapshot in time representing the currently agreed-upon body of requirements for a specific release)
  2. Reviewing proposed requirements changes and evaluating the likely impact of each change before approving it
  3. Incorporating approved requirements changes into the project in a controlled way
  4. Keeping project plans current with the requirements
  5. Negotiating new commitments based on the estimated impact of requirements changes
  6. Tracing individual requirements to their corresponding designs models, source code, and test cases
  7. Tracking requirements status and change activity throughout the project

Problems

Best Practices for improuvement

Knowledge

  • Train requirements analysts
  • Educate user reps and managers about requirements
  • Train developers in application domain
  • Create a glossary

Project Management

Project managers must manage scope, mitigate risks, keep everyone on schedule and provide the proper communications to people at all levels.
  • Define change-control process
  • Establish change control board
  • Perform change impact analysis
  • Baseline and control versions of requirements
  • Maintain change history
  • Track requirements status
  • Measure requirements volatility
  • Use a requirements management tool
  • Create requirements traceability matrix

Requirements Management

  • Select appropriate life cycle
  • Base plans on requirements
  • Renegotiate commitments
  • Manage requirements risks
  • Track requirements effort
  • Review past lessons learned

Elicitation

  • Define requirements development process
  • Define vision and scope
  • Identify user classes
  • Select product champions
  • Establish focus groups
  • Identify use cases
  • Identify system events and responses
  • Hold facilitated elicitation workshops
  • Observe users performing their jobs
  • Examine problem reports
  • Reuse requirements

Analysis

  • Draw context diagram
  • Create prototypes
  • Analyze feasibility
  • Prioritize requirements
  • Model the requirements
  • Create a data dictionary
  • Allocate requirements to subsystems
  • Apply Quality Function Deployment

Specification

  • Adopt SRS template
  • Identify sources of requirements
  • Uniquely label each requirement
  • Record business rules
  • Specify quality attributes

Validation

  • Inspect requirements documents
  • Test the requirements
  • Define acceptance criteria