CPRE Übungsfragen

• config = released version of req

trace from originin until implementation

outside the invoice the invoice item cannot exist

• Modelling Context

  • not part of system, but will affect it

  • to explain with

    • context diagram for external interfaces (like describe the context and system is a blackblox)

      

    • UML use case diagram for overview of use classes

      

• Structure and Data

  • input/output oriented

  • to explain with

    • UML class diagram

      

    • use cases (e.g. described with a template)

• Function and Flow

  • goal-oriented

  • to explain with

    • UML activity diagram

      

    • data modell, class modell (abstract and hard to learn)

    • flow chart

• State and behaviour

  • state-dependet

  • to explain wiht

    • UML state diagram

      

    • activity diagram

    • use case diagram

    • state charts

    • interaction diagram

  
  

• dokument templates können eher helfen nichts zu vergessen. Bei Phrase templates geht es nur um einzelne Reqs, da kann immer etwas vergessen werden

• Aus Modellen ist es möglich automatisierte Testfälle zu generieren, es muss jedoch für diesen Fall “korrekt” modelliert sein

A) und E) sind i.d.R. keine Req Dokumente

• greyzones are okay “???” can be used, but should be clarified within the process of development

• only direct interfaces/connections are needed

• state diagramm zeigt nur den kleinen Ausschnitt von einem Status/Zustand. Es können keine anderen Infos (was außenrum passiert) angezeigt werden

• context diagramm only shows what is outside the system

• natural language can be used for any kind of req

  • B) is wrong because of “mainly”

  • D) is correnct because it is also for quality reqs AND other

• is a means = ist ein Mittel

Wikipedia ist das Problem, an sich sind Referenzen gut und gewünscht (z.B. ins eigene Glossar)

• If you write “This” there should be at least a link/reference. Better write down what you mean

• Order is not needed, can be done afterwards with e.g. Prio in View/Filter

• auch durch die passive formulierung, ist trotzdem klar wer was macht “by the system”

• Bei “each” vorsichtig sein, immer gegenprüfen ob es eine Bedingung gibt oder eine andere Möglichkeit, die auch Beschrieben werden muss. Wenn nicht, kann man das aber nutzen

• phrase template is used for single reqs

• A) ist die Beschreibung von “document template”

• Stakeholder sind unterschiedlich und haben unterschiedliche Meinungen/Arbeitsweisen/Wissen/etc.

Bereich zwischen System Grenze und Kontext Grenze

Minimum viable product

• explorations Technik zur validierung von Anforderungen

• Functional Req

• Quality Req

• or user story:

  • “as a <role> I want to <goal> so that <benefit>”

• or use case for interaction between user (driver) and system (car) in the context (box)

• document template

  • iso/IEEE/company/….

  • checklist

• strucutre template

• Prototyp:

  • Explorative

    • wireframes (e.g. on paper)

    • mockups (real system w/o real function)

    • native prototypes (system part is implemented realisticly)

  • evolutionary

    • MVP

    • MMP (mim marketable product)

simple and short at the beginning

• elicitation

  • from stakeholders or other sources like affected documents (norms, standards)/influencers/system (other competing)

• documentation

  • adequalely description

• validation

  • review in early stage

  • non-validated reqs are useless

• management

  • structured and prepared for different roles

• funktional -> what

  • input/output of a system

• quality -> how

  • non-functional

  • properties that are testabe with metrics or derive functions

• constraints -> limit us

  • legal

  • cultural

  • process

  • other components

  • orga/tech

• reduce risk of wrong system

• understood problems

• estimationg effird and cost

• prereq. for testing

• make desicions in timely manner

• respects

• prioritizes

• reviews

• communicates

• changes

• formulate in to target-oriented and conscientuous manner

• provides reqs

• introduce into the subject area

• End user (Prio1 and largest group)

• clustered user groups

• personal (fictuinal characters)

• representatives

1. value = benefit - cost, will help build right system

2. stakeholder (most focus)

3. shared understanding (common basis, what is implizit and what is explizit)

4. context (where/how is the system used)

5. problem-requirement-solution

6. validation

7. evolution (change)

8. innovation (new)

9. systematic and disciplined work