Software Requirements – 5. fejezet: Establishing the Product Vision and Project Scope

Áttekintés: Ez általában egy Vision and Scope doksiban testesül meg. Ez tartalmazhatja a business requirementeket is (bár általában ezt job külön doksiba kitenni). Ha nincs egy közös kép a software-ről és egy hatáskör definiálva a projectről, akkor a résztvevők soha nem fognak megállapodni a követelményekben. Ezen kívül a Vision and Scope doksi nagyban segítheti a Requirement Change Control Process-t (csak rápillantunk a scope-ra, és könnyebben eldönthetjük, hogy a change in scope vagy out of scope).

A product vízió definiálása Business Requirementeken keresztül

A Product Vision:

• közös nevezőre hozza a project résztvevőit
• mi a product, és mivé válhat
• teljes egésszében tekinti a productot
• általában nem vagy lassan változik

A Project Scope Statement:

• meghatározza, hogy a hosszú távú product víziónak mely része tartozik az adott projectbe
• meghúzza a határokat (mi kerül be az adott projectbe és mi nem)
• meghatározza a project limitjeit
• a részletei a Requirement Baseline-okban vannak definiálva
• sokkal dinamikusabban változhat mint a Product Vision.

Ütköző Business Requirementek

Mivel a követelmények több különböző forrásból származnak így lehetnek köztük ütközőek. A Project Sponsor feladata, hogy feloldja ezeket az alapján, hogy project alapvető céljai szerint mi hordozza a maximális üzleti értéket. Ugyancsak a Sponsor feladata, hogy feloldja a konfliktusokat a project különböző résztvevői között…
Ha a project résztvevői szabadjára vannak engedve, akkor túl sok lesz a követelmény, túl komplikált a rendszer.

Business Requirements and Use Cases

A business requirement-ek meghatározzák:

• A business task-okat (Use Cases)
• A mélységet vagy szintet, ahol ezek a Use Casek implementálva lesznek (pl.: manuális, automatikus)

(Itt nagyon high level Use Casek-re kell gondolni)…

Vision and Scope Document

Tulajdonosa (irója/szerkesztője) a project szonzor. (Persze Requirement Analyst is dolgozhat rajta). Template:

1. Business Requirements

leirja az előnyöket amiket amiket az új rendszer biztosít. (Projects are launched in the belief that the new product will make the world a better place in some way for someone.)

1.1. Background

általános leírás a helyzetről ami az új projecthez vezetett.

1.2. Business Opportunity

market opportunity, solution for a problem, complete customer solution

1.3. Business Objectives and Success Criteria

Összefoglalja az előnyöket, megszámlálható/mérhető módon.

Pl.: Pénzügyi célok, Nem pénzügyi célok, %-ok, etc.

1.4. Customer or Market Needs

• Tipikus ügyfél szükségletei az adott piacon. Kiemelve azok, amelyeket az uj product fog biztosítani.

1.5. Business Risks

Piaci verseny, fejlesztési idő, fogadtatás, fejlesztési problémák, negatív hatások a business-re, kompatibilitás, migráció.

Ezeknek a kockázatoknak a valószínűsége.

2. Vision of the Solution

• Strategic vision for the system that will achieve the business objectives.

2.1. Vision Statement

For  [target customer]

Who  statement of the need or opportunity]

The  [product name]

Is  [a product category]

That  [key benefit, compelling reason to buy or use]

Unlike  [primary competitive alternative, current system, or current business process],

Our product  [statement of primary differentiation and advantages of new product].

2.2. Major features

• hangsúlyozni azokat, amik megkülönböztetik a versenytársaktól/legacy producttól.

2.3. Assumptions and Dependencies

A résztvevők feltevéseit rögzíteni, hogy a többi project member is át tudja nézni.

Rögzíteni a külső függőségeket amik befolyásolhatják a project időtartamát, stb.

3. Scope and limitations

“The System is and what is not.”

Definiálja az elképzelést és a tervezett megoldásokat.

A limitek meghatározzák, hogy mikre nem lesz képes a rendszer.

3.1. Scope of the Initial Release

Major feature set of the initial release.

Koncentráljunk azokra a feature-ökre amelyektől a legnagyobb business value-t remélünk.

3.2. Scope of the Subsequent Releases

• Mint az initial release-nél. De hangsűlyosabb a timing.

3.3. imitations and Exclusions

A határvonal definiálása – mi esik kívül az adott producton.

A kizárt feature-ok, amelyek nem lesznek megvalósítva.

4. Business Context

Business Issues

Project résztvevő kategóriák

Management hierarchy

4.1. Stakeholder Profiles

Stakeholders are the individuals, groups, or organizations who are actively involved in a project, are affected by its outcome, or are able to influence its outcome

Szerintem itt lehetne definiálgatni az egyes projectek vezetőit, a CCB tagjait, a project sponsorokat, stb.

4.2. Project Priorities

A hatékony döntéshozáshoz a project résztvevőinek meg kell egyezniük a prioritásokban.

A software project 5 dimenziója:

• features
• quality
• schedule
• cost
• staff

Mindegyikhez kell egy értéket rendelni a következőkből:

• constraint (show stopper)
• driver (must have)
• degree of freedom (nice to have)

A project manager dolga, hogy meghatározza prioritásokat. Nem lehet minden constraint of driver, kell egy bizonyos fokú szabadság a projecthez…

4.3. Operating environment

availability, reliability, performance and integrity requirements

Defining System Architecture.

A kontextus diagram

A Scope leírja a határokat és kapcsolatokat a fejlesztett rendszer és a külvilág között (Külső rendszerek, End Userek, stb.). A kontextus diagram ugyanezt teszi grafikusan. Ez a legmagasabb szintű folyamatábra a productról. Példa a könyvből: (nekem nem igazán tetszik…)

A lényeg az átláthatóság. Így könnyebb tisztázni a project részleteit a project résztvevői között.

Tartsuk a Scope-ot fókuszban!

Új requirementek esetén mindig ellenőrizzük, hogy ez belül van-e az eredeti Scope-on. A scope módosítható, de csak nagyon indokolt esetben. Amennyiben a scope módosul, általában a project egyéb tényezőinek is módosítanunk kell (pl.: schedule vagy resourcing).

Software Requirements – 4. fejezet: The Requirement Analyst

A business (requirements) analyst segít a project résztvevőinek megtalálni a különbséget aközött amit a customer mond hogy szeretne, és amire tényleg szüksége van.

A BA szerepe

A business analyst összegyüjti, analizálja, dokumentálja és validálja a project résztvevőinek követelményeit. A BA az elsődleges csatorna a customerek és a developerek között.

“One of my consulting clients discovered that they could inspect requirements specifications written by experienced analysts twice as fast as those written by novices because they contained fewer defects.” – miért nem képesek ezt nálunk megérteni?

Az analyst feladatai:

• Business requirementek definiálása: A business requirementek leírások/állítások a customer elképzeléseiről.

• A project résztvevőinek és a user class-oknak az azonosítása (A “Vision and Scope” dokument segíthet)

• A requirementek kigyűjtése: Proaktívnak kell lenni (Gyűlölöm ezt a szót…). Információgyüjtési technikákat kell alkalmazni (Interview, workshop, doksi analízis, Létező rendszerek visszafejtése, …)

• Requirementek analizálása: A származtatott requirementek tükrözzék a customer szükségleteit. Kiszűrni a többértelmű/ütköző követelményeket. Részletek kidolgozása – funkcionális követelmények (a részletezettség szintje Projectről Projectre változhat).

• Requirement Specifikáció írása (SRS dokument)

• Requirementek modellezése: néha hasznos lehet a követelményeket nem csak szövegesen megjeleniteni… (Grafikusan, matematikailag, prototípussal)

• Requirementek validálása: A BA-nak meg kell győződnie, hogy a követelményrendszer kielégíti a customer szükségleteit. Ugyancsak át kell néznie, hogy a design, kód, és Test Case-ek helyesen értelmezik a business requirementeket.

• Követelmények priorizálása

• Requirement management: establishing the baseline and managing the changes.

Alapvető Business Analyst Készségek:

“An effective analyst combines strong communication, facilitation, and interpersonal skills with technical and business domain knowledge and the right personality for the job”

- Halgatási készség
- Kérdező készség
- Analitikusi készség
- Előkészítési készség
- Megfigyelő készség
- Írói készség
- Szervezői készség
- Modellező készség
- Kreativitás

BA készítése

Nehéz képezni. A sok “soft skill” miatt, ami inkább embercentrikus mint technikai. A BA-k háttere különböző lehet:

• Korábbi User: Beszéli a “userek nyelvét” és ismeri a jelenlegi rendszereket, de nem ért a szoftware fejlesztéshez.

• Korábbi fejlesztő: “The stereotypical “geek” isn’t the most socially adroit of human beings.” Neki a business domain-ról kell többet tanulnia, és a júzerekkel való kommunikációról.

• Domain Expert (Subject Matter Expert): Nagyon sokat tud a rendszerről. Inkább a userhez áll közelebb.

Az együttműködő munkakörnyezet kialakítása:

A software projectek sokszor az analyst, fejlesztők, userek, managerek, és a marketing kapcsolatára épülnek. A felek nem mindíg bíznak egymásban. Ezért fontos a jó munkakörnyezet kialakítása.

Software Requirements – 3. Fejezet: Good Practices for Requirements Engineering

Knowledge – domain specifikus tudás

Sok fejlesztőnek kell business analyst szerepet betöltenie a munkája során. Ezért hasznos lehet tréningezni őket a projectek előtt, hogy megszerezzék a szükséges domain specifikus tudást. A következő training-ekre lehet szükség:

- Requirement analyst training: Hogy tudják mi az a req. analysis.
- Stakeholder training: Hogy megértsék az egész process-t.
- Developer training: hogy legyen domain specifikus tudás.

Hasznos lehet glossary-t készíteni, ahol leírjuk egy-egy domain specifikusan használt szó értelmét (pl.: order).

Requirements Elicitation – Követelmények Kigyűjtése

- Define a requirements development process (How to elicit, analyze, specify and validate requirement)
- Write a vision and scope document (A business requirementek vannak benne. Ad egy képet a projectről mindenkinek…)
- Identify user classes and their characteristics (Milyen csoportok fogják használni)
- Select a product champion for each user class (Ez hülyeség… úgyis az ügyfél dönt.)
- Work with user representatives to identify use cases. (Ez fontos lenne. Minden user class -ból kellene egy user. A Use Case-ek nagyon fontosak szoktak lenni…)
- … (a többi butaság vagy megvalósíthatatlan)

Requirement Analysis – Követelmények Elemzése

Itt bunthatók szét a high level requirementek részletekre. A következő dolgok lehetnek fontosak:
- Context diagram: hogyan illeszkedik az új fejlesztés a rendszerbe.
- UI or Technical Prototypes: egyrészt segíthet a requirement gyüjtésben, másrészt tesztelhető vele a megvalósíthatóság.
- Analyze requirement feasibility
- Prioritize the requirements: melyek a launch critical, melyek a nice to have feature-ok. Mit lehet vágni, ha csúszik a project.
- Model the requirements: Segíthet felismerni a követelmények közti kapcsolatokat/ellentmondásokat.
- Create a data dictionary: mindenki a projecten egyértelműen tudja miről van szó.
-…

Requirements Specification – Követelmények Leírása

Business Requirementek: A Vision and Scope doksiban
User Requirementek: Use Case -ekben
Functional/Non-Functional Requirementek: az SRS-ben.

Fontos:
- Használjunk SRS Templatet. - A funkcionális requirementek visszakövethetőek legyenek a forrás business requirementjükig. - Egyedi Requirement Id-k használata (a követelmények egyértelművé tételéhez) - …

Requirements Validation

- A requirement statementek helyesek és kielégítik az ügyfél igényeit - Teszteljük a követelményeket/Use Caseket. - Kérjük meg az ügyfelet, hogy állítson fel Acceptance Criteriát a productra.

Requirements Management

A project időtartama alatt a követelmények módosulhatnak.

- Change Control Board: Tagjai a kulcs pozícióban lévő (döntéshozó) szereplők. Feladata: Eldönteni mely változtatásokat kell megvalósítani, és melyek esnek kívül a scope-on.

- Define a requirements change-control process - Establish a change control board - Perform requirements-change impact analysis ( segíti a CCB döntését) - Establish a baseline and control versions of requirements documents - Maintain a history of requirements changes - Track the status of each requirement (proposed, approved, implemented, or verified) - Use a requirements management tool - Create a requirements traceability matrix

Project Management

- Select an appropriate software development life cycle: Ki kell választani azt a project életciklust (a company standardok közül), ami legjobban illeszkedik az adott feladathoz.

- Base project plans on requirements: Iterativ módszer. A Project plant és a schedule-t a requirementek alakulása alapján kellene updatelni. Először csak az elsőként felmerülő funkcionális requirementek alapján, aztán folyamatosan updatelve őket.

- Renegotiate project commitments when requirements change: Ha új requirement jön, meg kell vizsgálni, megoldható-e az adott erőforrásokkal adott idő alatt. Ha nem, ujra kell tárgyalni a project resource struktúráját.

- Document and manage requirements-related risks

- Track the effort spent on requirements engineering

Getting Started with New Practices

Itt egy 3×3 -as impact – difficulty tábla van, amelyben priorizálva vannak a fent leírt feladatok.

A Requirements Development Process

Iterative process of software requirements:

Ha egy egész projectre szeretnénk megvszgálni a szükséges lépéseket, akkor a következő ábra lehet nagyon hasznos:

Software Requirements – 2. Fejezet: Követelmények az Ügyfél szemszögéből

Ez a fejezet hivatott elemezni/leírni a “customer – developer” kapcsolatot, ami nagyon fontos egy Project sikeréhez.

Laza példa: Gerhárd megkéri Cintiát, hogy a csapatával fejlesszen ki egy vegyianyag nyilvántartó szoftvert. Gerhárd elmondja, hogy mi az elképzelése. Cintia viszont requirementeket követel, de nem kap…

“Part of the requirements problem results from confusion over the different levels of requirements: business, user, and functional. Gerhard stated some business requirements, … However, Gerhard can’t describe the user requirements because he is not an intended user of the system. Users, in turn, can describe the tasks they must be able to perform with the system, but they can’t identify all the functional requirements that developers must implement to let them accomplish those tasks.”

Who is the Customer?

“… a customer is an individual or organization who derives either direct or indirect benefit from a product.”

A customer osztálynak két fontos csoportja van:
1. Manager (customer who is paying for or sponsoring a software project)
2. User ((vagy End Users) can describe the tasks they need to perform with the product and the quality characteristics they expect the product to exhibit.)

“Unfortunately, both kinds of customers might not believe that they have the time to work with the requirements analysts who gather, analyze, and document the requirements. Sometimes customers expect the analysts or developers to figure out what users need without a lot of discussion.” – Ez mennyire így van

The Customer-Development Partnership

- Rights of the Customer:

1. Expect analysts to speak your language. (business vocabulary)
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. Expect analysts and developers to treat you with respect and to maintain a collaborative and professional attitude throughout your interactions.
6. Have analysts and developers provide ideas and alternatives both for your requirements and for implementation of the product.
7. Describe characteristics of the product that will make it easy and enjoyable to use.
8. Be given opportunities to adjust your requirements to permit reuse of existing software components.
9. Receive good-faith estimates of the costs, impacts, and trade-offs when you request a change in the requirements.
10. 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.

- Responsibilities of the Customer

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.
10. Respect the processes the analysts use for requirements engineering.

Sign-Off

Lényege: egy requirement baseline felállítása, amivel a továbbiakban lehet dolgozni.

Meg kell érteni mind a developereknek mind a customernek, hogy mi is az a sign off. A customer sokszor azt hiszi, ez egy jelentés nélküli dolog, amit meg kell ejteni, különben a developerek nem kezdenek el fejleszteni. Míg a developerek azt hiszik, hogy a requirementek mostantól kőbe vannak vésve, és minden változtátsi kisérletet elutasítanak…

Csapda: Ne használjuk a sign-off -ot fegyverként. Ez egy fontos mérföldkő, de megfelelő körülmények között a követelmények változhatnak.

Ez nagyon jó. Ha lesz rá lehetőségem, biztos becopyzom valamelyik requirement doksiba. Olyan mint egy eskü szövege:

… a requirements specification sign-off page should therefore read something like this: “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.”

Software Requirements – 1. Fejezet: Alapvető szoftver követelmények

Ez ilyen bevezető jellegű fejezet. Próbál átfogó képet adni…

Kezdetnek egy bugyuta példa: A user nem tudja megváltoztatni a nevét. (mert a családi állapota nem változott…)

Sok szoftver probléma adódik azokból a hibákból, amelyek a követelmények összegyüjtése, dokumentálása, megbeszélése és módosítgatása során keletkeznek. Ilyen hibák lehetnek például:
- informális információ gyüjtés
- burkolt/rejtett funkcionalitások
- több értelmű vagy nem kommunikált feltevések
- Elégtelenül definiált követelmények
- lezser módosítás management

Sok cég még mindíg kevésbé hatékony módon kezeli az alapvető projekt feladatokat. Ennek tipikus eredménye egy várató szakadék: – a különbség akközött amit a programozó szerint neki csinálni kellene, és amit az ügyfél valóban szeretne.

A requirement process resztvevői elég sokan lehetnek:
- Ügyfél, aki megrendeli a szoftvert
- Felhasználó (júzer) aki használni fogja.
- Requirement Analyst
- Developer
- Tesztelők
- Doksi írók
- Project Managers
- Jogi személyzet
- Sales, Marketing, …

Hüha: A résztvevők együttműködve izgalmas terméket (programot) tudnak összehozni, ami boldoggá teszi az ügyfelet, és elégedettséggel tölti el a programozót.

“Because requirements are the foundation for both the software development and the project management activities, all stakeholders must be committed to following an effective requirements process.”

Tipikus hibák:
- The project’s vision and scope are never clearly defined.
- Az ügyfél túl elfoglalt, hogy időt szánjon a req. managementre
- Felhasználó pótlékok alkalmazása: pl PM, aki megmondja, hogy a juzer igy szeretné, pedig nem is.
- Csak néhány “expert” fejében léteznek a követelmények.
- Az ügyfélnek minden követelmény kritikus, nem prioritizálja őket.
- A fejlesztők kétértelmű vagy hiányzó információk esetén kénytelenek tippelni
- A kommunikáció a developerek és a userek közt a UI megjelenéséről szól és nem a funkcionalitásáról.
- Lezárás után is folyamatosan változtatja a customer a reqiirementeket.
- A project scope-ja nő, amikor a requirementek változnak, de a schedule csúszik, mert nincs elég resource.
- Requirement change control process hiánya
- A customer kér funkcionalitásokat, amelyeket a user soha nem fog használni.
- Kedvencem: The specification is satisfied, but the customer is not.

Definiciók:

“… a requirement is “anything that drives design choices” (Lawrence 1997) …”

“… Requirements are…a specification of what should be implemented. They are descriptions of how the system should behave, or of a system property or attribute. They may be a constraint on the development process of the system…”

A requirementek különböző szintjei:
1. Business Requirements: Business requirements represent high-level objectives of the organization or customer who requests the system.
2. User Requirements: User requirements describe user goals or tasks that the users must be able to perform with the product. Valuable ways to represent user requirements include use cases, scenario descriptions, and event-response tables.
3. Functional Requirements: Functional requirements specify the software functionality that the developers must build into the product to enable users to accomplish their tasks, thereby satisfying the business requirements.
4. System Requirements: The term system requirements describes the top-level requirements for a product that contains multiple subsystems

Requirementek létrehozása/kezelése

Requirements Development
- elicitation
- analysis
- specification
- validation

Requirements Management

“…establishing and maintaining an agreement with the customer on the requirements for the software project…”

When Bad Requirements Happen to Nice People (Díjnyertes alcím)

- Insufficient User Involvement: A fejlesztők azt hiszik, tudják mit akar a User, ezért kihagyják.
- Creeping User Requirements: Közben becsúszhatnak új requirementek. De egy tiszta visionnal és scope-pal el lehet hárítani.
- Ambiguous Requirements: A különböző emberek különbözőképpen értelmezik. Tiszta sor.
- Gold Plating: Ne fejlesszünk olyat, amit nem kértek.
- Minimal Specification: egy vázlat spec elég lehet egy kis projecten szorosan együtt dolgozó teamnek.
- Overlooked User Classes: User Taxonomy fontossága
- Inaccurate Planning: Kellene egy új rendszer. Mikor lesz kész!

A Magas minőségű Requirement Process előnyei: (Megéri? Hát, elvileg ezek lehetnek az előnyei)

- Fewer requirements defects
- Reduced development rework
- Fewer unnecessary features
- Lower enhancement costs
- Faster development
- Fewer miscommunications
- Reduced scope creep
- Reduced project chaos
- More accurate system-testing estimates
- Higher customer and team member satisfaction

A Kiválló követelmények jellegzetességei:
- Complete: fully describe the functionality to built.
- Correct
- Feasible: Meg kell tudni valósítani őket.
- Necessary: Valóban szükséges legyen.
- Prioritized: ha vágni kell.
- Unambiguous: egyértelmü
- Verifiable

A Requirement Specifikáció (mint process) követelményei:
- Complete: Nem marad ki requirement.
- Consistent: nincsenek conflictok.
- Modifiable: A req. set módosítható.
- Traceable: A módosítások követhetőek.

Software Requirements, Second edition

Első olvasónaplóm:
Software Requirements, Second edition
by Karl E. Wiegers
MS Press

Most ennek a fejezeteit jegyzetelgetem. Csak, hogy később is emlékezzek…

A könyv 4 fő részből áll:
I. Software Requirements: Mit, Miért és Ki
II. Software Requirements Development
III. Software Requirement Management
IV. Implementing Requirements Engineering