SwArcDocRequirements

Requirements

Introduction

Purpose

Vocabulary

Derived: Child requirements are a decomposition of the parent, usually required because eachchild will be allolcated to a different entity(Mu06, 54).
Orphaned: A requirement, whos parrent was deleted. The orphaned requirement needs to be: Deleted, Reparented or reclassified as Secondary.
Primary: External requirement with contractaual value/weight. (Can occur at any level???? (how???))
Secondary: Has no parent and is not an external requirement. Not VOC. Often originate (bec54).
Orphaned: A requirement, whos parrent was deleted. The orphaned requirement needs to be: Deleted, Reparented or reclassified as Secondary.
Primary: External requirement with contractaual value/weight. (Can occur at any level???? (how???))
Secondary: Has no parent and is not an external requirement. Not VOC. Often originate because of design constraints or consideration unknown to the next layer up in the hierarchy, or because a Primary requirement is missing. No contractual value.
non-functional requirement: Constraints and quality goals.
User requirements: encompass the tasks that users need to accomplish with the system and the users expectations of performance, usability, and other quality attributes.
Fit criterion: it is an acceptance criterion(Rob06,c10,p28). Rob06's tag for the formal requirement text.
Well maybe not entirely, see (Rob06,c9,p5).
Description: The product shall make it easy for a buyer to find his chosen music.
Rationale: Music buyers are used to convenience and will not tolerate slow or awkward searches for their chosen tracks.
Fit Criterion: The average music buyer shall be able to locate any piece of music within six seconds, using no more than three actions.

Reference

Mu06 - Requirements Management Fundamentals CICI3131
Iee98 4.2 Properties (Iee98,p4)

Overview

Maintain glossary of terms(Mu06, 26)
Put background info in the start of the requirement doc(Mu06, 26)
The product of requirements development is a common understanding among the project stakeholders of the needs that are being addressed(Wei03,71).
TODO V - List the external events that could stimulate your system to behave in specific ways. Create an eventresponse table that shows the state the system is in when each event is received and how the system is to respond(Wie03,97).
In real systems, meeting the nonfunctional requirements often is more important than meeting the functional requirements in the determination of a system's perceived success or failure(Robert Charette 1990).

%X% TODO C What is the difference between a requirement class and a requirement type? I use 'type' for pattern identification.

Is 'Business', 'Non-functional' etc. then examples of classes?

The intention of a requirement:

A well-defined problem is a set of criteria according to which proposed solutions either definitely solve the problem or definitly fail to solve tit, along with any ancillary information, such as whcih materials are available to solve the problem(Kov99,28).
An open-ended problem is a situation in which we believe that some improvement is possible, but we have no definite criteria for measuring improvemetn. Discovering good criteria is, itself, part of the problem(Kov99,28).

Requirement development

This section deals with the issue of getting from problem statement to requirements. This is about discovering the right/relevant requirement in order to get the product right.%STOPINCLUDE%

Iee98 IEEE Guide for Developing System Requirements Specifications IEEE Std 1233, 1998. Edition ISBN 0-7381-0337-3
Iee04

Requirement production process

We want to get from the fluffy StoryCard to the real requirement(s).

So we need to understand what problem we are solving and why we want to solve it. What do we expect to get out og it.

Brainstorm, with yourself, on various aspects of the problem domain
- What problems are there (challenges)
- How can it be implemented
What is the goal or purpose of the action/operation (was 5Y) 1 Describe the Rationale
- It explains why the requirement is important and how it contributes to the product's purpose(Rob06,c10,p28). 1 Identify the RequirementType
- See (Rob06,c10,p27) 1 If multiple methods exist do a design analysis and select the best solution 1 Do a UseCase and/or a [SipocProcess]SIPOC analysis. 1 Write the Requirement criterion

%INCLUDE{ExtractRequirementsFromVoc}%

Introduction to Requirement development

Stating a problem is easy; writing up the requirements to get the problem solved, now that, is hard. Darn hard.

Abstractly the process consists of two steps:

1. StoryCard's: Capturing the Customer/Developers want. The fuzzy needs. If it is a process then do a UseCase/SIPOC.
1. Analysis: Discovering what it's all about. Domain knowledge.
1. Design: Deciding how to go about it. This is where all the solution options are evaluated and the optimal option is selected, and the reason for selecting it is documented.
1. Write system requirement specification :
1. Software requirements:
1. User requirements:
1. Reviews:
ArchitechtureConcepts

Words have meaning

Handling: takes responsibility and acts on ...
Manage: Set-up take down, distribute, make decissions.
x: Will log the information, but will not take remedy actions.

Ambiguous Terms	Ways to Improve Them(Wie03,117)
acceptable, adequate	Define what constitutes acceptability and how the system can judge this.(Wie03,117)
as much as practicable	Don't leave it up to the developers to determine what's practicable. Makeit a TBD and set a date to find out.(Wie03,117)
at least, at a minimum, not more than, not to exceed	Specify the minimum and maximum acceptable values(Wie03,117)
between	Define whether the end points are included in the range.(Wie03,117)
depends on	Describe the nature of the dependency. Does another system provide input to this system, must other software be installed before your software canrun, or does your system rely on another one to perform some calculations or services?(Wie03,118)
efficient	Define how efficiently the system uses resources, how quickly it performs specific operations, or how easy it is for people to use.(Wie03,118)
fast, rapid	Specify the minimum acceptable speed at which the system performs some action.(Wie03,118)
flexible	Describe the ways in which the system must change in response to changing conditions or business needs.(Wie03,118)
improved, better, faster, superior	Quantify how much better or faster constitutes adequate improvement in a specific functional area.(Wie03,118)
including, including but not limited to, and so on, etc., such as	The list of items should include all possibilities. Otherwise, it can't be used for design or testing.(Wie03,118)
maximize, minimize, optimize	State the maximum and minimum acceptable values of some parameter.(Wie03,118)
normally, ideally	Also describe the system's behavior under abnormal or non-ideal conditions.(Wie03,118)
optionally	Clarify whether this means a system choice, a user choice, or a developer choice.(Wie03,118)
reasonable, when necessary, where appropriate	Explain how to make this judgment.(Wie03,118)
robust	Define how the system is to handle exceptions and respond to unexpected operating conditions.(Wie03,118)
seamless, transparent, graceful	Translate the user's expectations into specific observable product characteristics.(Wie03,118)
several	State how many, or provide the minimum and maximum bounds of a range.(Wie03,118)
shouldn't	Try to state requirements as positives, describing what the system will do.(Wie03,118)
state-of-the-art	Define what this means.(Wie03,118)
sufficient	Specify how much of something constitutes sufficiency.(Wie03,118)
support, enable	Define exactly what functions the system will perform that constitute supporting some capability.(Wie03,118)
user-friendly, simple, easy	Describe system characteristics that will achieve the customer's usage needs and usability expectations.(Wie03,118)

Requirement criterion format

<WHO> shall <WHAT> <WHERE> <WHEN> <CONSTRAINTS>
<CONSTRAINT>, <WHO> has the ability to <WHAT>
WHO: Everyone, Group, Subject
WHAT: Predicate, action, result
WHERE: Process point, item location
WHEN: Process point, speed
CONSTRAINT: Process point, validation
Be inspired by SMART (Specific, Measurable, Atainable, Relevant, Time bound)
"to be" verb
- Shall and must: Means required.
  - Don't switch between the word you use, someone might get the idea that there is an implied priority.
- will: Means a statement of fact (future intent)
- Should or May: specifies optionality (goals)

structured natural language, augmented with graphical models, remains the most practical way for most software projects to document their requirements(Wie03,106).

Characteristics of good requirements

From course

Feasible: It might be necessary to do a blitz to understand whether or not a requirement is feasible. If the delopers aren't able to say whether or not they would be able reach the goal of a requirement, then the writeter of the requirement has two options:
- Start a prototype project.
- Do a blitz. (same as a prototype project, just on a very small scale)
- Write the minimum negotiated with the customer, then add a 'Goal' section to the requirement.
- Also(Wei03,p15)
Necessary: What is the driver in this requirement, VOC or VOB.
- Why is this requirement needed?
- Is this requirement specifying an essential capability.
- Would it make a difference if the requirement was omited?
- If the requirement is a Secondary type, then you need to thorougly review wether there is a business reason for having this requirement.
- Also(Wei03,p15)
Complete: The requirement must state a need, in and of itself.
- If the requirement contains things like TBD then it is not done.
- If the reason for the requirement isn't obvious you must provide a description. The description can either be part of the requirement, or part of the document proper.
- Also(Wei03,p15)
Consistent:
- A requirement isn't allowed to contradict other requirements.
- Requirements use consistent terminology for a given item.
- Requirement must be consistent with respect to the parent requirement.
Verifiable: Can you prove the requirement has been met.
- Demonstrate
- Test - If you can't devise tests to tell whether the requirement was correctly implemented, it's probably ambiguous or lacks necessary information(Wie03,119).
- Analysis
- Inspection
- Also(Wie03,p16)
Correct: Accurately describe the functionality to be delivered.
- Also(Wei03,p15)
Clear:
- Unambiguous, ensure that the requirement only has a single interpretation. But don't attempt to go for 'water tight'
  - Also(Wei03,p15)
- Single function. Ensure that the requirement can't be split into two or more requirements.
- Long explanations, might need to be given it's own paragraph in the document proper
- Easy to read, stated simply and concisely
- Use terminology the target audience understands.
- Use proper grammar and spelling. It realy detracts from the reading and concentration on the issue if you don't
- Avoid unnecessary detail
- Use enough detail to guarantee requirements are implemented correctly downstream.
Traceable: A requirement must have a unique identifier, for reference use, in traceability matrix, implementations etc.
- Link to higher level requirements
- Link to use cases
- Link to VOC/VOB
- Link to Test cases
- Link to Story cards
- Link to Project and version the requirement belongs to.
- If a requirement is changed, from one project version to the next, then the unique id must be changed.
- Identifier: FEAT-TYPE-nnnnn
  - FEAT:
    - PLTF - Platform
    - TODO V Is there a way to generictly define the cardinal FEATures?
  - TYPE
    - FR - Functional Requirement
    - AR - Architechtural Requirement
    - FD - Functional Design. Design desissions on the FR level.
    - AD - Architechtural Design. Design on the AR level.
Leveled: Keep the requirement at a consistent hierarchical level.
- See 'Peer Leveling'
Design-independent: What - not how.
- Requirements should not force a specific design.
- Do not state implementation. Functionality or performance is acceptable.
- Requirements elicitation should indeed focus on the what, but there's a gray area'not a sharp line'between analysis and design. Hypothetical h o ws help to clarify and refine the understanding of what users need. Analysis models, screen sketches, and prototypes help to make the needs expressed during requirements elicitation more tangible and to reveal errors and omissions(Wei03,78).
Maintainable:
Prioritized:
- Also(Wei03,p15)
Grouped:
Granularity: write individually testable requirements(Wie03,118).
- 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(Wie03,118).
- If the tests you envision are numerous and diverse, perhaps several requirements are lumped together that ought to be separated.(Wie03,118)

%X% Integrate these with the list above... Each requirement should possess the following properties(IEEE1223,18):

Abstract: Each requirement should be implementation independent.
Unambiguous: Each requirement should be stated in such a way so that it can be interpreted in only one way.
Traceable: For each requirement it should be feasible to determine a relationship between specific documented customer statement(s) of need and the specific statements in the definition of the system given in the SyRS as evidence of the source of a requirement.
Validatable: Each requirement should have the means to prove that the system satisfies the requirements.
Categorization: To support the analysis of requirements, the requirements should be categorized by their identification, priority, criticality, feasibility, risk, source, and type. Each of these categories is described in more detail in (IEEE1223,19).

%X% Also integrate these: (Iee98, p4)

Unique: Each requirement should be stated only once.
Normalized: Requirements must not overlap. Do not refer to other requirements or the capabilities of other requirements.
Linked set: Explicit relationships should be defined among individuals requirements
Consistent: All; level of detailed, styele of statements and presentation.
Bounded: boundaries, scope and context for the set of requirements should be identified.
Modifiable:
Configurable: Version control
Granular: This should be the level of abstraction for the system being defined.
Write complete sentences that have proper grammar, spelling, and punctuation. Keep sentences and paragraphs short and direct(Wie03,117).
Use the active voice. (For example, 'The system shall do something,' not 'Something shall happen.')(Wie03,117)
Use terms consistently and as defined in the glossary. Watch out for synonyms and near-synonyms. The SRS is not a place to creatively vary your language in an attempt to keep the reader's interest(Wie03,117).
Decompose a vague top-level requirement into sufficient detail to clarify it and remove ambiguity(Wie03,117).
State requirements in a consistent fashion, such as 'The system shall' or 'The user shall,' followed by an action verb, followed by the observable result. Specify the trigger condition or action that causes the system to perform the specified behavior. For example, 'If the requested chemical is found in the chemical stockroom, the system shall display a list of all containers of the chemical that are currently in the stockroom.' You may use 'must' as a synonym for 'shall,' but avoid 'should,' 'may,' 'might,' and similar words that don't clarify whether the function is required(Wie03,117).
When stating a requirement in the form 'The user shall...,' identify the specific actor whenever possible (for example, 'The Buyer shall...')(Wie03,117).
Use lists, figures, graphs, and tables to present information visually. Readers glaze over when confronting a dense mass of turgid text(Wie03,117).
Emphasize the most important bits of information. Techniques for emphasis include graphics, sequence (the first item is emphasized), repetition, use of white space, and use of visual contrast such as shading (Kovitz 1999)(Wie03,117).
Ambiguous language leads to unverifiable requirements, so avoid using vague and subjective terms. Table 1 0-1 lists several such terms, along with some suggestions for how to remove the ambiguity(Wie03,117).
Write requirements specifically enough so that if the requirement is satisfied, the customer's need will be met(Wie03,118)
avoid unnecessarily constraining the design(Wie03,118)
Provide enough detail to reduce the risk of misunderstanding to an acceptable level, based on the development team's knowledge and experience.(Wie03,118)
If a developer can think of several ways to satisfy a requirement and all are acceptable, the specificity and detail are about right.(Wie03,118)
If a developer who reviews the SRS isn't clear on the customer's intent, include additional information to reduce the risk of having to fix the product later.(Wie03,118)
Avoid long narrative paragraphs that contain multiple requirements. Words such as 'and,' 'or,' and
'also' in a requirement suggest that several requirements might have been combined(Wie03,119).
Never use 'and/or' in a requirement; it leaves the interpretation up to the reader(Wie03,119).
Words such as 'unless' and 'except' also indicate multiple requirements(Wie03,119)
Sometimes the best way of representing a set of requirements, is to use a table(Wie03,119)
- 'ED-1 3. The Text Editor shall be able to parse documents in several formats that define laws in the jurisdictions shown in Table 10-2."(Wie03,119)
If any of the combinations don't have a corresponding functional requirement, put N / A (not applicable) in that table cell.(Wie03,119)
(Wie03,119)

Organizing requirements

Categorization(Iee98, p13)

Categorization(Iee98, p18) s7.3

Avoid forward references. As usual try listing them in an order where you don't have to do forward references.

Identification: Each requirement should be uniquely identified (i.e., number, name tag, mnemonic, buttons, hypertext). Identification can reflect linkages and relationships, if needed, or they can be separate from identification.
Priority: The customer should identify the priority of each requirement. This may be established through a consensus process among potential customers. As appropriate, a scale such as 1:10 or a simple scheme such as High, Medium, Low, Out, could be used for identifying the priority of each requirement.
Criticality: The analyst, working with the customer, should define the criticality of each requirement. Some requirements could have a low priority from the user's perspective, but nevertheless be essential for the success of the system. For example, a requirement to measure external ambient temperature could be essential to provide support to other requirements such as the maintenance of internal cabin temperature. This relationship should be identified so that if the primary requirement is removed by the customer, the supporting requirement can also be eliminated.
Stability: can be expressed in terms of the likelihood of expected changes to any requirement based on experience or knowledge of forthcoming events that affect the organization, functions, and people supported by the software systemRef. [5]. Examples of such events include political negotiations, proposed legislation or change regulations. The ratings typically are:
- High ' High probability of changing
- Medium ' Medium probability of changing
- Low ' Low probability of changing
Feasibility: The customer and analyst working together should identify the feasibility of including each particular requirement in the system, and classify each requirement by types of feasibility appropriate to the system domain. Feasibility could be based upon an understanding of such things as the current state of technology (e.g., commercially available components vs. original research), the customer's environment (e.g., readiness or capability to accept change), and the risk or cost associated with a particular requirement.
Difficulty: Rates the technical complexity of the requirementRef. [5]. This rating is will be assessed by the Project Office but not provided to the vendor or included in the RFP. It will be used internally to prioritize review, test, and evaluation. The vendors will evaluate difficulty in their own requirements analysis. The difficulty ratings typically are:
- High ' Very complex
- Medium ' Moderately complex
- Low ' Simple
Risk: Risk analysis techniques can be used to determine a grading for system requirements. In terms of their consequences or degree of risk avoidance, major risks are related to potential financial loss, environmental impact, safety and health issues, and national standards or laws.
Related Requirements: MOT thing.
Trace: You must be able to link the requirement with its higher source Ref. [6].
Source: Each requirement should be further classified by a label that indicates the originator. There may be multiple sources that can all be considered creators of the requirement. It is useful to identify the creator(s) of each requirement so that if requirements are unclear, conict, or need to be modified or deleted, it will be possible to identify the individual(s) or organization(s) to be consulted.
- Recording the originator of each requirement lets you know who to talk to if you discover conflicts(Wei03,p16).
Type: Requirements can also be categorized by one or more of the following types:
- Accessibility (e.g., different navigation paths for novice and experienced users);
- Availability (e.g., expected hours of operation);
- Compatibility to existing systems (e.g., uses analog telephone system as default mode);
- Conversion (e.g., will accept data produced by older versions of system);
- Documentation (e.g., on-line help facility);
- Environmental conditions (e.g., dust levels that must be tolerated);
- Ergonomic (e.g., use of particular colors to reduce eye strain);
- External interfaces (e.g., support for industry standard communication mode/format);
- Facility requirements (e.g., use of domestic electrical current);
- Growth capacity (e.g., will support an additional number of users);
- Input (e.g., receive EDI data);
- Installation (e.g., ability to put a new system into service).
- Maintainability (e.g., ease with which components can be replaced);
- Output (e.g., export a particular format);
- Performance (e.g., response time);
- Policy and regulatory (e.g., environmental protection agency policies);
- Quality provisions (e.g., minimum required calibration intervals);
- Reliability (e.g., mean time to failure);
- Safety (e.g., below specified limits for electrical magnetic radiation);
- Security (e.g., limits to physical, functional, or data access, by authorized or unauthorized users);
- Standards and technical policies (e.g., products to conform to ASME codes);
- Testing (e.g., support for remote diagnostics);
- Transportability (e.g., weight limits for portability);
- Training (e.g., includes tutorials or computer-based training);
Pattern Types:
- Accessibility
- Approval
- Availability
- Calculation Formula
- Capacity, Dynamic
- Capacity, Static
- Chronicle
- Comply-with-Standard
- Configurable Authorization
- Configuration
- Data Archiving
- Data Longevity
- Data Structure
- Data Type
- Documentation
- Extendability
- ID
- Information Storage Infrastructure
- Inquiry
- Installability
- Inter-System Interface (e.g. )
- Inter-System Interaction
- Living Entity
- Multi-Lingual
- Multiness
- Refer-to-Requirements
- Report
- Reporting Infrastructure
- Response Time
- Scalability
- Specific Authorization
- Technology
- Throughput
- Transaction
- Unparochialness ' should this be Universalism?
- Authentication, User
- Authorizations, User
- User Interface Infrastructure: A user interface infrastructure is a coherent set of components that together enable a user to interact with the system, excluding anything developed as part of a specific system, general underlying software (such as an operating system), and hardware(Wit07,163).
- Registration, User

%X% TODO V Link to Volere.

Does the 'Type' reflect the Why, the What or the How? I think the Why. Though to use a pattern, wont it have to be the What?

Ends up as Installation (PTLF-AR-13020)
- Cost reduction
- Resource usage/improvement
- Consolidation
- Flexibility
- Configuration
- Customization
- Efficiency?
Authorization, specific (PTLF-AR-13030)
- Flexibility
- Control
- Limitation
- Access
- Autherization(but this is the method)
()
- Technology (not for selecting)
- Comply-with-Standard
Shutdown
- Operations?
- Interface?

Pitfalls

Missing requirements:
Ambiguity:
Combining requirements together:
Let-out clauses:
Writing implementation requirements:
Speculation:
Vague terms:
Specif suggestions:
Specifying the impossible:
Incorrect assumptions:
Rambling:

Reviewing requirements

Upstream
Peer
- Stake holder
- test engineer
- Technical domain expert
Downstream
- Domain expert in the sub system areas affected by the requirements.

Only one requirement per line

Usually the requirement can be stated in one sentence. If you find yourself taking more than one sentence to describe it, then you may, in fact, be describing several requirements. If you use two verbs in the sentence, it might be that you are describing two requirements. It is good practice to write each requirement as a single sentence with a single verb(Rob06,c10,p34).

Traceability

Implementation Coverage
Decomposition Logic
Verification Coverage
Constraints and Information
Impact assessment

Doing requirement patterns

From SW Req Patterns Each requirement pattern contains the following sections:

Pattern name:
Basic details: The pattern manifestation, owning domain, related patterns (if any), anticipated frequency of use, pattern classifications, and pattern author.
- Pattern manifestation: The manifestation can convey one or more of the following things:
  - The pattern's version number.
  - The date the pattern was last changed.
  - The requirements approach (or author).
  - The customer organization (company name).
  - The requirements specification language (for example, English).
- Belongs to domain:
- Related patterns: This lists any other requirement patterns that apply to related situations. If it would be helpful, this item can also say a little about how the patterns relate to each other.
- Anticipated frequency:
- Pattern classifications: E.g.: Functional: Yes; Performance: Yes
- Pattern author:
Applicability: In what situations can the pattern be applied? And when can it not be applied?
Discussion: How do we write a requirement of this type? What does a requirement of this type need to consider?
Content: What must a requirement of this type say? What extra things might it say? This is the main substance of the pattern.
Template(s): A starting point for writing a requirement of this type'or more than one if there are distinct alternative ways.
Example(s): One or more representative requirement written using this pattern.
Extra requirements: What sorts of requirements often follow on from a requirement of this type? And what pervasive systemwide requirements might define something for all requirements of this type?
Considerations for development: Hints for software designers and engineers on how to implement a requirement of this type.
Considerations for testing: What do we need to bear in mind when deciding how to test this type of requirement?

approach to developing the FR+AR docs

the SRS must be comprehensive. Developers and customers should make no assumptions. If any desired capability or quality doesn't appear somewhere in the requirements agreement, no one should expect it to appear in the product(Wie03,107).

How to go about writing the FR and AR.

What is the FR for/who is the audience:

1 Write the preliminary Introduction chapter

TODO V Describe how to handle multi version products.

Chapters

Introduction:
- Purpose:
- Scope: Audience
- Acronyms:
- Definitions:
- References:
- Document Conventions:
- Reading Guide:
Operation: Give an overview of how the feature/product works.
- Overview:
- Operations aspects:
- Major system capabilities:
- User characteristics:
- Assumptions and dependencies:
- Operation scenarios:
- Quality attributes: List in priorities and describe how each attribute affects the product.
- User Documentation: List the user documentation components that will be delivered along with the executable software. These could include user manuals, online help, and tutorials. Identify any required documentation delivery formats, standards, or tools(Wie03,112).
FR:
- Constraints:
- HW:
- OE:
- Consolidation:
- Network:
External Interface Requirements:
- User Interfaces:
  - References to GUI standards or product family style guides that are to be followed(Wie03, 114).
  - Standards for fonts, icons, button labels, images, color schemes, field tabbing sequences, commonly used controls, and the like(Wie03, 114).
  - Screen layout or resolution constraints(Wie03, 114).
  - Standard buttons, functions, or navigation links that will appear on every screen, such as a help button(Wie03, 114).
  - Shortcut keys(Wie03, 114).
  - Message display conventions(Wie03, 114).
  - Layout standards to facilitate software localization(Wie03, 114).
  - Accommodations for visually impaired users(Wie03, 114).
  - Including screen mock-ups in the SRS to communicate another view of the requirements is helpful, but make it clear that the mock-ups are not the committed screen designs(Wie03,114).
- HW interfaces: Describe the characteristics of each interface between the software and hardware components of the system(Wie03,115).
- SW Interfaces: Describe the connections between this product and other software components(Wie03,115)
  - State purpose of the messages(Wie03,115)
  - State control items exchanged between the software components(Wie03,115)
  - Describe the services needed by external software components(Wie03,115)
  - Describe the nature of the intercomponent communications(Wie03,115).
  - Identify data that will be shared across software components(Wie03,115).
  - If data-sharing must be implemneted a specifi way, specify this as a constraint(Wie03,115)
- System Interface:
Network and Service Management:
Integration and testing:
Migration and upgrade:
Performance:
Service and features interactions:
Standards and interoperability:
Provisioning:
Appendices:
- Cross reference to SyRS, FIP etc:
- Driving requirements:

What is it good for?

How do I ensure that all requirements have been captured
How do I ensure that all requirements are covered
How do I present it correctly to the audience?

Customers, the marketing department, and sales staff need to know what product they can expect to be delivered.

Project managers: base their estimates of schedule, effort, and resources on the product description(Wie03,107).
SW dev: The SRS tells the software development team what to build(Wie03,107).
testing group: uses the SRS to develop test plans, cases, and procedures(Wie03,107).
Support and Maintenance: The SRS tells maintenance and support staff what each part of the product is supposed to do(Wie03,107).
Documentation writers: base user manuals and help screens on the SRS and the user interface design(Wie03,107).
Training personnel use the SRS and user documentation to develop educational materials(Wie03,107).
Legal staff: ensure that the requirements comply with applicable laws and regulations(Wie03,107).
Subcontractors: base their work on, and can be legally held to, the SRS(Wie03,107).

What requirement docs/types when

How do I define a standard structure for working out the path to the finished requirements list or code?

1 Perhaps list all stakeholders, 1 then for each stakeholder list what requirements each stakeholder contributes 1 then list when in the process flow the requirements will be contributed

How do you handle the requirement process if you want to create breakthrough/disruptive technology?

Why break the requirement development into phases? Because this is a busnines, you must have a business case for doing the project. There must be toll gates where it is possible to ditch the project if it turns out the project has lost the business case.

For each requirement type describe:

Who writes them
What are they used for
When are they written
Why should they be done
What is accomplished by going through that phase of the process, kind of like hochas?
FunctionalRequirements: Functional requirements are documented in a software requirements specification (SRS), which describes as fully as necessary the expected behavior of the software system(Wei03,7).
SystemRequirements
BusinessRules: include corporate policies, government regulations, industry standards, accounting practices, and computational algorithms(Wei03.8).
Quality attributes
Constraints

Seems like Worlds SRS is the same as Motorola's TRS, though it might only be the FR part?. So is (Wei03,7) SRS the same as IEEE's SyRS?

a feature is a group of requirements recognizable to a stakeholder that aids in making a purchase decision(Wei03,7)

Whenever someone proposes a new feature, use case, or functional requirement, the analyst must ask, 'Is this in scope?' If the answer is 'yes,' the requirement belongs in the specification. If the answer is 'no,' it does not. If the answer is 'no, but it ought to be,' the business requirements owner or the funding sponsor must decide whether to increase the project scope to accommodate the new requirement(Wei03,7).

Process according to Wie03

TODO V At least some of this would fit in at the Charter os SyRS level.

Requirements Development

Wei03,9

Identifying the product's expected user classes
Eliciting needs from individuals who represent each user class
Understanding user tasks and goals and the business objectives with which those tasks align
Analyzing the information received from users to distinguish their task goals from functional requirements, nonfunctional requirements, business rules, suggested solutions, and extraneous information
Allocating portions of the top-level requirements to software components defined in the system architecture
Understanding the relative importance of quality attributes
Negotiating implementation priorities
Translating the collected user needs into written requirements specifications and models
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

Requirement management

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

Questions to ask

Periodically ask, 'What are we assuming?' to try to surface those hidden thoughts(Wei03,p11): to ferret out those implicit requirenments.

Some of the most common requirements risks

Wei03, p11

Insufficient User Involvement:
Creeping User Requirements: To manage scope creep, begin with a clear statement of the project's business objectives, strategic vision, scope, limitations, success criteria, and expected product usage. Evaluate all proposed new features or requirements changes against this reference framework(Wei03,12).
- which changes to accept and the associated costs in time, resources, or feature trade-offs
Ambiguous Requirements:
- a reader can interpret a requirement statement in several ways.
- imprecise and insufficiently detailed requirements that force developers to fill in the blanks.
- See: Chapter 1 5, 'Validating the Requirements," On how to avoid ambiguity.
Gold plating:
- To reduce the threat of gold plating, trace each bit of functionality back to its origin so that you know why it's included(Wei03,p13).
Minimal specification:
Overlooked user classes:
- This could also be a type of user that has two different usage experience levels.
Inaccurate planning:
Missing requirements: ! Chapter 7 suggests some ways to find missing requirements.(Wei03,p17)
Resentment of the product: Users who are upset about having a new information system forced on them by management might not want to work with the software developers, viewing them as the harbingers of an undesired future(Wei03,p20).
- The analyst should work with the key user representatives and management sponsors to reconcile any conflicts.
Managers who override user-supplied requirements to suit their own agenda also can generate friction(Wei03,p20):

Ellicitation thingy

Wei03,21 Requirements Bill of Rights for Software Customers

Expect analysts to speak your language.
- You shouldn't have to wade through computer jargon when talking with analysts(Wei03,21).
Expect analysts to learn about your business and your objectives for the system.
Expect analysts to structure the information you present during requirements elicitation into a written software requirements specification.
Have analysts explain all work products created from the requirements process.
Expect analysts and developers to treat you with respect and to maintain a collaborative and professional attitude throughout your interactions.
Have analysts and developers provide ideas and alternatives both for your requirements and for implementation of the product.
Describe characteristics of the product that will make it easy and enjoyable to use.
Be given opportunities to adjust your requirements to permit reuse of existing software components.
Receive good-faith estimates of the costs, impacts, and trade-offs when you request a change in the requirements.
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.

Requirements Bill of Responsibilities for Software Customers

Educate analysts and developers about your business and define business jargon.
Spend the time that it takes to provide requirements, clarify them, and iteratively flesh them out.
Be specific and precise when providing input about the system's requirements.
- If you can't be precise, agree to a process to generate the necessary precision. This often involves some prototyping, in which you work with the developers in an incremental and iterative approach to requirements definition.
Make timely decisions about requirements when requested to do so.
Respect a developer's assessment of the cost and feasibility of requirements.
In collaboration with the developers, set priorities for functional requirements, system features, or use cases.
Review requirements documents and evaluate prototypes.
Communicate changes to the requirements as soon as you know about them.
Follow the development organization's process for requesting requirements changes.
Respect the processes the analysts use for requirements engineering.

Wei03 process

(Wei03,p37) The first seven steps are done only once, at the beginning of the project.

Define vision and scope (charter)
Identify user clases (Stakeholders?)
Identify user representatives
Identify requiremetns decision makers
Select elicitation techniques
- Workshop
- Survey
- Interview
- etc
Identify use cases
Prioritize use cases
Develop use cases
Specify quality attributes
Derive and document FR
Model the requirements
Review requirements specifications
Develop prototypes
Develop or evolve architecture
Allocate requiremetns to components
Develop test cases
Validate use cases, FR, analysis models and prototypes

Analyst role

Tell the stakeholders/user representatives what work/input you expect from them(Wei03,p40).

Requirement elicitation

From (Wei03,p40)

Interviews
Facilitated requirements workshops
Document analysis
Surveys
Customer site visits
Business process analysis
Work flow and task analysis
Event lists
Competitive product analysis
Reverse engineering of existing systems
Retrospectives performed on the previous project

Users naturally emphasize the system's functional requirements, so steer the discussions to include quality attributes, performance goals, business rules, external interfaces, and constraints(Wei03,p40).

Analysts should also review designs, code, and test cases that were derived from the requirements specifications to ensure that the requirements were interpreted correctly(Wei03,p41).

Learn how your collaborators prefer to communicate and avoid imposing your personal filter of understanding on what you hear the customers say. Watch for assumptions that underlie either what you hear from others or your own interpretation(Wei03,p42).

much code gets written to handle exceptions, so you must also probe for possible error conditions and determine how the system should respond(Wei03,42).

Customers are delighted with the product.
The developing organization is happy with the business outcomes.
The development team members are proud of the good work they did on a challenging and rewarding project.

Skill list(Wei03, 44-45)

Listening skills:
Interview and questioning skills:
Analytical skills:
Facilitation skills:
Observational skills:
Writing skills:
Organizational skills:
Modelling skills:
Interpersonal skills:
Creativity:

Requirements sources

TODO V This should probably be moved to the Charter or Pre-charte area.

Interviews and discussions with potential users(Wei03,59)
Documents that describe current or competing products(Wei03,59)
SyRS(Wei03,60)
Problem reports and enhancement requests for a current system(Wei03,60)
Marketing surveyes and user questionaires(Wei03,60)
Observing users at work(Wei03,60)
Scenario analysis of users tasks(Wei03,60)
Events and responses(Wei03,60)

User classes

Priorities the user classes, so some, important' class requests have a higher weight than other classes. Summary of (Wei03,61)

Remember the indirect users, like the customer who access the system through the bank teller(Wei03,62).

A user class need not be human, e.g. fuel system in a car is a user class(Wei03,62)

Document the user classes and their characteristics, responsibilities, and physical locations in the SRS(Wei03,62).

Consider building a catalog of user classes that recur across multiple applications(Wei03,63).

To bring the user classes to life, you might create a persona for each one, a description of a representative member of the user class(Wei03,p63)

From (Wei03,66)

Planning
- Refine the scope and limitations of the product
- Define interfaces to other systems
- Evaluate impact of new system on business operations
- Define a transition path from current applications
Requirements
- Collect requirements from other users
- Develop usage scenarios and use cases
- Resolve conflicts between proposed requirements
- Define implementation priorities
- Specify quality and performance requirements
- Evaluate user interface prototypes
Validation and Verification
- Inspect requirements documents
- Define user acceptance criteria
- Develop test cases from usage scenarios
- Provide test data sets
- Perform beta testing
User Aids
- Write portions of user manuals and help text
- Prepare training materials for tutorials
- Present product demonstrations to peers
Change Management
- Evaluate and prioritize defect corrections
- Evaluate and prioritize enhancement requests
- Evaluate the impact of proposed requirements changes on users and business processes
- Participate in making change decisions

Resolving requirements conflicts

If individual users disagree on requirements, the product champions decide.(Wei03,69)
If different user classes or market segments present incompatible needs, go with the needs of the most favored user class or with the market segment that will have the greatest impact on the product's business success.(Wei03,69)
managers who aren't members of the user class should defer to the product champion who represents their users.(Wei03,69)
When the product that the developers think they should build conflicts with what customers say they want, the customer should normally make the decision.(Wei03,69)
if marketing or product management presents requirements that conflict with what developers think they should build. As customer surrogates, marketing's input should carry more weight. Nevertheless, I've seen cases where marketing never said no to a customer request, no matter how infeasible or expensive.(Wei03,69)
- Sound a bit like the candy wrapper story in the sixsigma pricing book, where the NPV went out the window because of too straneous requirements.
(Wei03,69)

VOC

'What do you need to do?'(Wei03,71)
- Emphasizing user tasks rather than user interfaces(Wei03,71)
- focusing on root needs more than on expressed desires(Wei03,71)

Planning the requirements elicitation activities

Your plan should address the following items

Elicitation objectives(Wei03,71)
Elicitation strategies and processes(Wei03,72)
Products of elicitation efforts(Wei03,72)
Schedule and resource estimates(Wei03,72)
Elicitation risks(Wei03,72)
To facilitate clear communication, use the vocabulary of the application domain instead of forcing customers to understand computer jargon.(Wei03,72)
What could prevent the user from successfully completing a task?(Wei03,72)
Good open ended questions(Wei03,72)
- 'What else could...,'
- 'What happens when...,'
- 'Would you ever need to...,'
- 'Where do you get...,'
- 'Why do you (or don't you)...,'
- 'Does anyone ever...'
Rather than simply transcribing what customers say, a creative analyst suggests ideas and alternatives to users during elicitation.(Wei03,73)
After each interview, document the items that the group discussed and ask the interviewees to review the list and make corrections.(Wei03,73)
Timebox discussion(Wei03,74). allocate a set time for discusssing a topic, then move on after time has run out, this avoids rat-holing and nigling.
Consider running multiple workshops in parallel to explore the requirements of different user classes.(Wei03,74)
Workshop participants should include(Wei03,74):
- the product champion(Wei03,74)
- other user representatives(Wei03,74)
- perhaps a subject matter expert(Wei03,74)
- a requirements analyst(Wei03,74)
- a developer.(Wei03,74)

Classifying VOC

Business requirements(Wei03,75)
Use cases or scenrios(Wei03,75)
- 'I need to [do something]' is probably describing a use case(Wei03,76)
Business rules(Wei03,75)
- only certain user classes can perform an activity under specific conditions(Wei03,76)
Functional Requirements(Wei03,75)
Quality attributes(Wei03,75)
- Statements that indicate how well the system performs some behavior or lets the user take some action are quality attributes(Wei03,75).
External interface requirements(Wei03,75)
Constraints(Wei03,75)
- Record the rationale behind each constraint(Wei03,77)
Data definitions(Wei03,75)
SolutionIdeas(Wei03,75)
- Someone who describes a specific way to interact with the system to perform some action is presenting a suggested solution(wie03,78).
  - The analyst needs to probe below the surface of a solution idea to get to the real requirement(wie03,78).

Information that doesn't fit into one of these buckets might be one of the following(Wei03,75):

A requirement not related to the software development, such as the need to train users on the new system(Wei03,75)
A project constraint, such as a cost or schedule restriction (as opposed to the design or implementation constraints described in this chapter)(Wei03,75)
An assumption(Wei03,75)
A data requirement, which can often be associated with some system functionality (you store data in a computer only so that you can get it out again later)(Wei03,75)
Additional information of a historical, context-setting, or descriptive nature(Wei03,75)

Finding missing requirements

Trace system requirements, use cases, event-response lists, and business rules into their detailed functional requirements to make sure that the analyst derived all the necessary functionality(Wei03,79).
Represent complex logic using decision tables or decision trees to make sure you've covered all the possible situations(Wei03,79),

Business rules are requirements too

TODO V This section might have to be moved somewhere else, possibly to the Architecture part or TRS part? Because business rules can influence multiple applications, organizations should manage their business rules as enterprise-level(Wie03,102).

Facts: Simple truths about the business(Wie03,99)
- Every container has a unique bar code identifier(Wie03,99)
- Sales tax is not computed on shipping charges.(Wie03,99)
Constraints: restrict the actions that the system or its users may perform(Wie03,100) See also TypeOfConstraints.
- A borrower who is less than 1 8 years old must have a parent or a legal guardian as cosigner on the loan(Wie03,100)
- A library patron may place up to 1 0 items on hold.(Wie03,100)
Inference: a rule that establishes some new knowledge based on the truth of certain conditions.(Wie03,101).
- Inferences are often written in the 'if/then' pattern also found in action-enabling business rules, but the 'then' clause of an inference implies a fact or a piece of information, not an action to be taken(Wie03,101).
- If the vendor cannot ship an ordered item within five days of receiving the order, then the item is back-ordered.(Wie03,101)
Action Enablers: A rule that triggers some activity under specific conditions(Wie03,101)
- 'If <some condition is true or some event takes place>, then <something happens>' is a clue that someone is describing an action enabler.(Wie03,101)
- If the customer ordered a book by an author who has written multiple books, then offer the author's other books to the customer before accepting the order.(Wie03,101)
Computations: are performed using specific mathematical formulas or algorithms.(Wie03,101)
- Whereas action-enabling business rules lead to specific software functional requirements to enforce them, computational rules can normally serve as software requirements as they are stated(Wie03,101).
- The unit price is reduced by 10% for orders of 6 to 1 0 units, by 20% for orders of 1 1 to 20 units, and by 35% for orders of more than 20 units(Wie03,101).
(Terms): (Wie03,99)

Static/Dynamic is how likely it is to change, prbably should be changed to 'Stability' : Hi/Med/Low.

BR-CSTR-001

Discovering business rules

Policies: Why do we have to do it like that(Wie03,104).
Data models: How are these pieces of data related(Wie03,104).
Actor decisions: What may the user do next(Wie03,104).
Events: What can and cannot happen(Wie03,104).
System decisions: How does the system know what to do next(Wie03,104).
Object life cyckles: What causes a change in the object's state(Wie03,104).
Formulas: How is that number calculated(Wie03,104).
Regulations: What does the government require(Wie03,104).

Graphical tools

VOC to analysis model

Actors (use-case diagram)
Entities or their attributes (ERD)
Classes or their attributes (class diagram) | Verb | Actions, things a user can do, or events that can take place |
Processes (DFD)
Use cases (use-case diagram)
Relationships (ERD)
Transitions (STD)
Activities (activity diagram)|

In the VOC statement, highlight the significant unique nouns/verbs as follows(Wie03,126)

nouns: bold.
verbs: italic

Don't create both a decision table and a decision tree to show the same information; either one will suffice(Wie03,139).

Data flow diagram(DFD)

A DFD identifies the transformational processes of a system, the collections (stores) of data or material that the system manipulates, and the flows of data or material between processes, stores, and the outside world(Wie03,126).

Notation: (Wie03,127)
- Arrows: Dataflow.
- Box: Terminator.
- Circle: Process.
- Parrallel lines: Data store.
Review: When customer representatives review a DFD, they should make sure that all the known processes are represented and that processes have no missing or unnecessary inputs or outputs.

The Context Diagram is the highest level DFD. Next level, after the context diagram, is the level 0 DFD, where the the buble of the Context Diagram is cut into major processes.

Place data stores only on the level 0 DFD and lower levels, not on the context diagram(Wie03,129).
Processes communicate through data stores, not by direct flows from one process to another(Wie03,129).
- Similarly, data cannot flow directly from one store to another; it must pass through a process bubble(Wie03,129).
Don't attempt to imply the processing sequence using the DFD(Wie03,129).
Name each process as a concise action: verb plus object (such as Generate Inventory Reports)(Wie03,129).
Use names that are meaningful to the customers and pertinent to the business or problem domain(Wie03,129).
Number the processes uniquely and hierarchically. On the level 0 diagram, number each process with an integer. If you create a child DFD for process 3, number the processes in that child diagram 3.1 , 3.2, and so on(Wie03,129).
Don't show more than eight to ten processes on a single diagram or it becomes difficult to draw, change, and understand. If you have more processes, introduce another layer of abstraction by grouping related processes into a higher-level process(Wie03,129).
Bubbles with flows that are only coming in or only going out are suspect. The processing that a DFD bubble represents normally requires both input and output flows(Wie03,129).

Entity-relationship diagram(ERD)

Notatoion:
- Box: Entities are physical items(including people) or aggregations of data items important to the business(Wie03,129)
- Diamond: Relationship, which identify the logical and numeric linkages between pairs of entities(Wie03,130).
- one-to-one:
- one-to-many:
- many-to-many:
Review:
- ask the reviewers to check whether the relationships shown are all correct and appropriate(Wie03,130).
- ask the reviewers to identify any possible relationships with entities that the model doesn't show(Wie03,130).
'What information do you need to perform this step?'
'What information does this step produce that we should store?'
By correlating the answers for all process steps, I found
- steps that needed data that no one had available.
- Other steps produced data that no one needed.

State-transition diagram(STD)

Notatoion:
- Arrow: Allowed state changes/transistions(Wie03,131)
- Box: Possible system states(Wie03,131)
- Label: Text on each transition arrow, Events or conditions that cause the transition to take place. The label might identify both the event and the corresponding system response.(Wie03,131)
Review:
- ask the reviewers to check whether the relationships shown are all correct and appropriate(Wie03,130).
- ask the reviewers to identify any possible relationships with entities that the model doesn't show(Wie03,130).

Dialog map

A user interface also can be regarded as a finite-state machine. Only one dialog element (such as a menu, workspace, dialog box, line prompt, or touch screen display) is available at any given time for user input. The user can navigate to certain other dialog elements based on the action he takes at the active input location(Wie03,134).

The dialog map represents a user interface design at a high level of abstraction. It shows the dialog elements in the system and the navigation links among them, but it doesn't show the detailed screen designs(Wie03,134).

Dialog maps are related to system storyboards, which also include a short description of each screen's purpose (Leffingwell and Widrig 2000).(Wie03,134).

Notation:
- Arrow: Allowed navigation option(Wie03,134)
- Box: dialog element(Wie03,134)
- Label: condition that triggers a user interface(Wie03,134)
  - User action(Wie03,134)
  - Data value, e.g invalid user input(Wie03,134)
  - System condition, e.g. detect printer out of paper(Wie03,134)
  - Combination of the above, e.g. typing a menu option number and pressing Enter(Wie03,134)

Decision tables

Find a better description of it, I don't quit understand it yet.

Decision tree

Notatoion:
- Arrow:
- Box: Possible outcome(Wie03,140)
- Diamond:

%INCLUDE{QualityAttributes}%

Reviewing

peer deskcheck: in which you ask one colleague to look over your work product(Wie03,173).
passaround: in which you invite several colleagues to examine a deliverable concurrently(Wie03,173).
walkthrough: during which the author describes a deliverable and solicits comments on it(Wie03,173).
ftr:
Inspection: (Wie03,174) Have Six or fewer participants(Wie03,175). or use a moderator(MOT)
- Inspectors
  - Author(s)
  - Upstream
  - Downstream
  - Peer(s)
  - External interface responsible
  - System
- Roles
  - Author
  - Moderator
  - Reader
  - Recorder
- Entry criteria(Wie03,175)
  - Conforms to template
  - Spell checked
  - visually checked for layout errors.
  - All references are available
  - Line numbers are printed on the doc, for reference.
  - All openm issues are marked TBD.
  - The moderator didn't find more than three major defcts in a ten minute examination of a representative saple of the document(Wie03,176)

Inspection

Planning: Author and moderator plan together(Wie03,176)
- Expect 2-4 pages per hour.
- The team's previous inspection data
- The amount of text on each page
- The specification's complexity
- The risk of having errors remain undetected
- How critical the material being inspected is to project success
- The experience level of the person who wrote the SRS
Overview meeting:
Preparation: Read the whole document and find defects.
- I estimate that each page take 5 min to read.
- Downstream rate their understanding of each req on a scale of 1-5(Pleeger 2001) 1=huh, 5=got it.
Inspection meeting:
Rework:
Follop up:

Exit criteria

All issues raised during the inspection have been addressed(Wie03,178).
Any changes made in the document and related work products were made correctly.
The revised document has been spell-checked.
All TBDs have been resolved, or each TBD's resolution process, target date, and owner has been documented.
The document has been checked into the project's configuration management system.

Checklist for use-cases

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 exception 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 complete?
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?

Checklist for requirements

(Wie03,179)

Organization and Completeness
- Are all internal cross-references to other requirements correct?
- Are all requirements written at a consistent and appropriate level of detail?
- Do the requirements provide an adequate basis for design?
- Is the implementation priority of each requirement included?
- Are all external hardware, software, and communication interfaces defined?
- Are algorithms intrinsic to the functional requirements defined?
- Does the SRS include all the known customer or system needs?
- Is any necessary information missing from a requirement? If so, is it identified as a TBD?
- Is the expected behavior documented for all anticipated error conditions?
Correctness
- Do any requirements conflict with or duplicate other requirements?
- Is each requirement written in clear, concise, and unambiguous language?
- Is each requirement verifiable by testing, demonstration, review, or analysis?
- Is each requirement in scope for the project?
- Is each requirement free from content and grammatical errors?
- Can all the requirements be implemented within known constraints?
- Are all specified error messages unique and meaningful?
Quality Attributes
- Are all performance objectives properly specified?
- Are all security and safety considerations properly specified?
- Are other pertinent quality attribute goals explicitly documented and quantified, with the acceptable trade-offs specified?
Traceability
- Is each requirement uniquely and correctly identified?
- Is each software functional requirement traced to a higher-level requirement (for example, system requirement or use case)?
Special Issues
- Are all requirements actually requirements, not design or implementation solutions?
- Are the time-critical functions identified and their timing criteria specified?
- Have internationalization issues been adequately addressed?

It could be a good idea to give only a sub set of the checklist groups to each inspector. The inspector would then focus on the particular area. (Is this perhaps a form of 'Missing the Gorilla' ???)

Large inspection teams

(Wie03,180)

'Writing Requirements' To be integrated

This is just a scratch pad on how to write requirements....

These requirements should be communicated in a structured manner to ensure that the customer and technical community are able to do the following(IEEE1223,11): a. Identify requirements that are derived from other requirements; a. Organize requirements of different levels of detail into their appropriate levels; a. Verify the completeness of the set of requirements; a. Identify inconsistencies among requirements; a. Clearly identify the capabilities, conditions, and constraints for each requirement; a. Develop a common understanding with the customer of the purpose and objectives of the set of requirements; a. Identify requirements that will complete the SyRS.

Environment affects on req:(IEEE1223,14) a. Political; a. Market; a. Standards and technical policies; a. Cultural; a. Organizational; a. Physical.

As previously defined, a well-formed requirement is a statement of system functionality (a capability) that can be validated, that must be met or possessed by a system to solve a customer problem or to achieve a customer objective, and that is qualified by measurable conditions and bounded by constraints. This definition helps in the classification of general customer requirements. Requirements can be taken from customer needs and can be derived from technical analysis. The definition provides a means for distinguishing between requirements as capabilities and the attributes of those requirements (conditions and constraints). Constraints may be functional or nonfunctional. An example of a nonfunctional constraint might be that the system is to be painted a particular shade of blue solely for nonrequired decorative purposes(IEEE1223,17).

Capabilities: are the fundamental requirements of the system and represent the features or functions of the system needed or desired by the customer. A capability should usually be stated in such a way that it describes what the system should do. The capability should also be stated in a manner that is solution independent(IEEE1223,17).
Conditions: may limit the options open to a designer. It is important to identify conditions as attributes of capabilities, not as primary capabilities, to ensure that the requirements clearly define the need without imposing unnecessary bounds on the solution space(IEEE1223,17).
Constraints: are requirements that are imposed on the solution by circumstance, force, or compulsion. Constraints limit absolutely the options open to a designer of a solution by imposing immovable boundaries and limits(IEEE1223,18).
- Constraints may be identified as stand-alone requirements (i.e., not bounding any specific capability), or as constraints upon individual capabilities.

E.g. Move people from New York to California at a maximum speed of 5300 km/hr.

Capability: Move people between Los Angeles and New York
Condition: Cruising speed of 2500 km/hr
Constraint: Maximum speed of 5300 km/hr

ScratchPad for Requirement development

ScratchPad level holder

Scenarios and such

If we use the Six Sigma way to do the development, then we could start by using the DMADV concept. This model could possibly be used at all levels of the development work. From the top; the business level. To the bottom(choose another word, more inspiring) where the code is being written.

Possible scenarios:

Brand spanking new idea
- Automating a manual process
  - The process might not be fully understood or documented, SIPOC can help you here.
GUI design
Game - Something completely new, level B or C dev. Start by describing what you want to do and why.
0 - Capture:
1 - Define: The main point here is to gain domain expertise, identifying the premises/boundaries
- Describe problem
- Do SIPOC/Use Case, multilevel (TODO: Describe how to do multilevel SIPOC/UseCases
- Identify the Major parts
- Define Top level areas, req?
2 - Measure:
3 - Analyze:
4 - Design:
5 - Validate:

TODO: Move this to a general chapter.

%T% This process is applicable at all levels of the requirement writing. A very simple model talks about:
- System requirement
- Design
- Coding
Theses days though, development can become quite complex, and the methods described in this chapter can be used at any level of the development model.
Rigorous research and definition of requirement is possible only in relation to a specific design pattern. [Kov99]

FIP to WBS

List what is new
What needs to be ported
What needs to be developed.
List resources
- CPU
- Memory
- Net
- Storage
- Platform
- Serial
- Power
- USB
- Optical media
Describe the existing process for creating the base product
Describe the new process for creating the product.
Foreach of the steps describe the requirements, pre and post conditions and invariance.
Identify which areas needs to be changed.
Generate WBS
Write SOW
Estimate
Identify risks

Capture - Story carding

Before you can get started on the road to requirements and code, you need to capture the ideas.

You can capture the idea in StoryCards.

Write the story cards
Ask the 5Y - why,why,why,why,why; So the story card should hold the root reason for doing it in the first place.
Do the planning game(Beck00, 86)
Write Statement of Work(SOW)
Order the cards
Go to analysis phase on the first batch. Execute in iterations.

What's in a story card

(Bec00, 88)

Id: So a specific card can be referenced. And cards can be easily distinguished from each other.
Tag?: Should some sort of tag be provided so everyone can have an easy, and unique, way of referencing it.
Project it belongs to: So that the Story cards can be grouped to each project.
Headline: Summary of what is to be achieved.
Description: Description of what is to be achieved. This could also be a link to a UseCase?
Priority:
Customer:
Tech:
Complexity/difficulty:
What if not done: What happens if it isn't implemented? Where did I get
Estimation: This is the tech estimation of the work. This might change through time, before the work is committed. It would probably be nice to be able to track these estimations. But at the same time, the estimation is also dependent on the SOW, so they would have to be tracked together.
SOW: A tech description of what work is expected. This is needed in order to remeber what is expected to be done. I find it easy to forget what I that was part of the work, after I have estimated something. So It's nice to have a SOW with estimations in it. This could be implemented as a simple entry with
- work to be done
- Estimation of time needed; Best,Worst -case and expected.
Risk: What risks are associated with this work.
Dependency: Does this depend on something else.
Type of work:
New:
Fix
Enhancement:
Date: Why?

Why do it

Customer: Needs to be able to see/understand the fluffy requirement. How important is this to the customer, what happens if it isn't implemented
Developer-implementer: Understand what it is that needs to be implemented and why.
Developer-improvement: When changes needs to be done later, the developer might need to be able to know/understand how it all came about.
Manager-dev: Understand how and where to fit this into the schedule.
QA: Continues improvement. Gather relevant statistics.

Requirements types

Software requirements express the needs and constraints placed on a software product that contribute to the solution of some real-world problem. (Kot00)
At its most basic, a software requirement is a property which must be exhibited in order to solve some problem in the real world. (Iee04, p2-1)
An essential property of all software requirements is that they be verifiable. (Iee04, p2-1)
- Both the software requirements and software quality personnel must ensure that the requirements can be verified within the available resource constraints.(Iee04, p2-1)
Requirements have other attributes in addition to the behavioral properties that they express.
- resources and a status value to enable project progress to be monitored
Product parameters: are requirements on software to be developed(Iee04, p2-2)
Process parameters: is essentially a constraint on the development of the software(Iee04, p2-2)
- choice of verification technique
- The software shall be written in Ada.
- use of particularly rigorous analysis techniques, to reduce faults which can lead to inadequate reliability.
Process requirements: See Process parameters.
Functional requirements: describe the functions that the software is to execute;
Nonfunctional requirements: are the ones that act to constrain the solution.
performance requirements:
maintainability requirements:
safety requirements:
reliability requirements:
constraints: See Nonfunctional requirements.
Quality requirements: See Nonfunctional requirements.
Emergent Properties: requirements which cannot be addressed by a single component, but which depend for their satisfaction on how all the software components inter operate. E.g. Throughput requirement for a call center(Iee04, p2-3)
system: means - an interacting combination of elements to accomplish a defined objective. These include hardware, software, firmware, people, information, techniques, facilities, services, and other support elements, as defined by the International Council on Systems Engineering (INCOSE00). (Iee04, p2-3)
System requirements: are the requirements for the system as a whole. It is the "black-box" description of what the system should do, in terms of the system's interactions or interfaces with its external environment.
Software requirements: In a system containing software components, software requirements are derived from system requirements.
user requirements: requirements of the system's customers or end-users. Sub Part of the system requirements.
Requirements Elicitation: concerned with where software requirements come from and how the software engineer can collect them.
requirements capture: See: Requirements Elicitation
requirements discovery: See: Requirements Elicitation
requirements acquisition: See: Requirements Elicitation
QualityAttributes: See SixSigmaDmadvMeasure.
Requirements Elicitation(Iee04, p2-4)
- stakeholders are identified
- relationships established between the development team and the customer
- Identify Sources
- Goals: high-level objectives. provide the motivation for the software, but are often vaguely formulated.
Where do they come from?
- Domain knowledge:
- Stakeholders: The software engineer needs to identify, represent, and manage the “viewpoints” of many different types of stakeholders. [Kot00]
- operational environment: Requirements will be derived from the environment in which the software will be executed. These may be, for example, timing constraints in real-time software or interoperability constraints in an office environment.
- organizational environment: Software is often required to support a business process, the selection of which may be conditioned by the structure, culture, and internal politics of the organization.
- Elicitation Techniques. %X% Does this resemble the Design part of DMADV
- Interviews:
- Scenarios:
- Prototypes:
- Facilitated meetings:
- Observation:
Requirement analysis
- Classification (Iee04,p2-6)
  - Functional/Non-functional requirements
  - derived from one or more high-level requirements
    - emergent property
  - imposed directly on the software by a stakeholder or some other source.
  - product or the process requirements.
  - requirement priority
  - scope of the requirement. Scope refers to the extent to which a requirement affects the software and software components. Some requirements, particularly certain nonfunctional ones, have a global scope in that their satisfaction cannot be allocated to a discrete component.
  - Volatility/stability. Some requirements will change during the life cycle of the software, and even during the development process itself. It is useful if some estimate of the likelihood that a requirement change can be made.
  - There is a strong overlap between requirements classification and requirements attributes
- Conceptual Modeling: to aid in understanding the problem, rather than to initiate design of the solution. Hence, conceptual models comprise models of entities from the problem domain configured to reflect their real-world relationships and dependencies.
  - data and control flows
  - state models
  - event traces
  - user interactions
  - object models
  - data models
  - %X% Is the above, what is described in the OOD book?
  - in almost all cases, it is useful to start by building a model of the software context. The software context provides a connection between the intended software and its external environment. This is crucial to understanding the software’s context in its operational environment
- Architectural Design and Requirements Allocation (Iee04, p2-7)
  - components that will be responsible for satisfying the requirements be identified.
  - This is requirements allocation–the assignment, to components, of the responsibility for satisfying requirements.
  - %X% What are components? how are they defined?
  - once a set of requirements has been allocated to a component, the individual requirements can be further analyzed to discover further requirements on how the component needs to interact with other components in order to satisfy the allocated requirements.
  - The mapping from real-world domain entities to software components is not always obvious, so architectural design is identified as a separate topic.
- Requirements Negotiation(Iee04, p2-7)
  - resolving problems with requirements where conflicts occur between two stakeholders requiring mutually incompatible features, between requirements and resources, or between functional and non-functional requirements, for example
  - consult with the stakeholder(s) to reach a consensus on an appropriate trade-off.
Requirements Specification
- system requirements are specified, the software requirements are derived from the system requirements, and then the requirements for the software components are specified.(Iee04, p2-8)
- System Definition Document(Iee04, p2-8)
  - defines the high-level system requirements from the domain perspective.
  - sometimes known as the user requirements document or concept of operations
  - Its readership includes representatives of the system users/customers (marketing may play these roles for market-driven software),
  - background information about the overall objectives for the system,
  - its target environment
  - a statement of the constraints,
  - assumptions,
  - and non-functional requirements.
  - conceptual models designed to illustrate the system context,
  - usage scenarios and the principal domain entities,
  - data,
  - information,
  - and workflows.
  - %X% is this like our FIP?
- System Requirements Specification(Iee04, p2-8)
  - Strictly speaking, system requirements specification is a systems engineering activity and falls outside the scope of this Guide. IEEE Std 1233 is a guide for developing system requirements. (IEEE1233-98)
  - Dav93; Kot00; Rob99; Tha97
  - A System Requirements Specification (SyRS) has traditionally been viewed as a document that communicates the requirements of the customer to the technical community who will specify and build the system. (Iee98,p4)
- (Iee04, p2-8)

System Requirements

The SyRS is the document that communicates the requirements of the customer to the technical community(Iee98, c4)
The SyRS is the results of (Iee98,s4.1)
- The definitions of need
- The operation concept %X% What is this?
- System analysis task %X% What is this?
The purpose of the SyRS is to provide a "black-box" description of what the system should do in terms of the system's interactions or interfaces with its external environment(Iee98, s4.3).
The SyRS should completely describe:
- all inputs
- all outputs
- required relationships between inputs and outputs.
Capture and state the fundamental needs of
- the customer
- Technical community
Properly form requirements
organize or group requirements into meaningful categories.
Identify technical requirements, but not the an implementation approach(Iee98, p5)
%X% What the Require servers(Iee98,p5)
The use of the SyRS is(Iee98, s4.4)
- Input for the 'System Design'??? (What is system design?)
- Write system verification plans.
- Writing test plans; HW and SW.
- Write test procedures(Iee98, s4.4) %X% This doesn't seem to make sense, wouldn't the test procedures be based off of the lower level Req specs?. Or are the test procedures here, the system test procedures? But if that is the case, why would you wait with these test until implementation???
- Used in Validation process, basis for FAT.

The audiences:

Customer
Technical community.

Creation

The SyRS get it's input from three entities(Iee98, s5):

Customer
Environment
Technical community.
Customer provided input
- e.g. StoryCards
- The customer input is probably a mix of levels, some of it should go into the charter some of it may be rather low level.
  - e.g. The use of a certain colour scheme perhaps because it a company standard, is a lower level thing.
- So it would make sense that all the customer input is captured on story cards, and the story cards are then assigned to the general level where it belongs.
  - %X% What should the various levels be called?
Concept of operations: The (Iee98,s5.1.1a) Description sounds a great deal like a subset of the Charter.
- todo is this indention suppose to be here?
  - goals - 'Business Opportunity' ?
  - objectives - Project Objective
  - general desired capabilities of the potential system. (%X%What is 'potential system?)
Possibly this is the Project description.
System concept: 'Concept of Operations + preliminary interface design for the system and other explicit requirements(Iee98,s5.1.1b).
Marketing specification:
- todo is this indention suppose to be here?
  - Features list - Project Description
StoryCard list.
- todo is this indention suppose to be here?
  - Feature Scope - Project scope?
  - Feature Priority - (X%X Possibly this is features at a lower level?, Kano survey)
At a more detailed level; the planning game.
- todo is this indention suppose to be here?
  - Features needed to provide edge in marketplace -
  - context/boundary interaction with existing systems
  - Cost/benefit analysis - Business Results/ Benefit to external customers
At a more detailed level; per story card
- todo is this indention suppose to be here?
  - Required delivery schedule - (project) Schedule
At a more detailed level; the planning game.
Request for proposal(RFP): The FIP, used for doing the M13 estimated and org SOW, then used for M11 estimates.
External system interfaces:
- Operational:
- Computer to computer:
- Electrical:
- Data links and protocols:
- Telecommunications lines:
- Device to system, system to device:
- Computer to system, system to computer:
- Environmental sense and control interface:
- %X% Sounds to me that the above doesn't need to go before the system requirement, but that it at the very least must be part of the system requirement. The RFP is probably something that goes before the decision makers. Kind of the charter, so they can gate the go/no-go.

Doc outline

Introduction:
System purpose:
System Scope:
Definitions, Acronyms and abbreviations:
References:
System overview:
General system description:
System context:
System modes and states:
Major system capabilities:
Major system conditions:
Major system constraints:
User characteristics:
Assumptions and dependencies:
Operational scenarios:
System capabilities, conditions , and constraints:
Physical:
- Construction:
- Durability:
- Adaptability:
- Environmental conditions:
System performance characteristics:
System security:
Information management:
System operations:
- System human factors:
- System maintainability:
- System reliability:
Policy and regulations:
System life cylce sustainment:
System interfaces:

Method overview

A more detailed model would look thus[Rum91, 149]:

Idea capturing - Story carding
Analysis
- Identify the objects
  - Read problem statement
  - Read/write user manual
  - Talk to domain expert(s)
  - Talk to customer(s)???
  - Blitz
  - Real world model, %STAR% possibly a repeat of the Blitz.
- Write/update dictionary
- Describe associations between objects
- Describe attributes for the objects, and the links between the objects. [Rum91, 261]
- Testing access paths
- Grouping into modules
- Dynamic model
  - Sequence of interactions
    - Write use cases/scenarios for typical interactions.
    - Identify events between the objects and do an event trace for each scenario
    - Write flow diagram
    - Write State diagrams
    - Review consistency and completeness.
- Functional model
  - Data transformation
    - Identify input and output values
    - Show functional dependencies?????
    - Describe what each function does, does this really fit here?
    - Identify constraints, say huh?
    - Specify optimization criteria, this needs to be understood and embellished.
Review with stakeholders.
Design
- Identify how it can be done.
- Write up solutions options.
- For each solution option write up advantages and disadvantages
- Summaries, which option is selected and why.
Review with stakeholders.

Why do capture

The aim of these methods are to be able to write the correct requirements the first time.

In order to do that, it is necessary to understand:

What is needed
By Whom
How
When
Why

In order to write a requirement it is necessary to have domain knowledge.

What is and what isn't a requirement

What is design and what is requirement.

Don't waste you time trying to go for a water tight requirement.

Idea capturing - Story carding

Extract requirements from VOC

PAORE - PAckage Oriented Requirements Elicitation method
Replace Idioms
- e.g. 'He kicked the bucket last night.' meaning die.
Divide the sentence into more than one sentences if it is not a simple sentence(Kat02).
For each sentence
Make it a full and valid sentence.
- link-grammar accepts it
- Remove ambiguity, if possible. Perhaps write multiple sentences if the current one is ambiguous.
Reduce sentence list/pool
- Find alias words, like parking spot/parking place
- Do semantic decomposition; like 'mare' being horse/female/adult
What causes this problem
What is the result of the problem
How does the problem relate to
- Financial
- Process
- Innovation
- Customer satisfaction
- Employee growth and development
- (Resources)
  - I think this one should only be used if nothing else fits. There is no direct link to Cardinal Objectives.

Analysis

The analysis phase is all about getting domain knowledge so that intelligent/data driven decisions can be made.

Identify the objects

This is about identifying the static parts of the problem.

Read the problem statement
- Isolate the nouns [Rum91,153]
List what entities are involved
Identify the 'stakeholders', this might be a bit like the entities.
Write the user documentation - This might be a bit of a challenge until the first iteration of the analysis has been finished.
Blitz - It might be an idea to wait with the blitz, until the first iteration through the analysis has been finished.

It might be necessary to prune the list of objects. If the list is pruned, then there should be an explanation of why the objects where pruned. Possibly also document where you are keeping some objects. See also [Rum91,153]

%ICON{edittopic}% Could this process be a bit like the House of Quality process, I seem to recall some pruning activity.

Update dictionary

The purpose of the dictionary is to ensure that everyone is aligned on what the word means.

Avoiding misunderstandings.
remove ambiguity
make it easier for new project memebers to get into the flow/jargon of things.

%H% E.g. Decinding that all measures are done in the metric system, thus avoiding having to abort your billion dollar space faring object, using the big red button.

The dictionary is simply the word and the explanation, the explanation could be substantiated using illustrations.

Describe associations between objects

The reason for identifying the associations between objects is to find out if anything needs to be linked, and to prepare for the dynamic model.

Association: Often corresponds to
- %H% Class Person should not have an attribute employer; relate class Person and class Company by association Work-for [Rum91,156].
- Association is the description of links connecting Objects.
- Any dependency between two or more classes is an association[Rum91,156].
- A reference from one class o another is an association.
- Associations often correspond to stative verbs or verb phrases[Rum91,156]:
- Physical location: next to, part of, contained in.
- Directed actions: Drives
- Communication: Talks to, communicates with.
- ownership: Has, Part of, Owns
- condition: works for, married to, manages
- %ICON{wip}% MIS FITS: Consists of, Entered by, Entered on, Authorized by, accesses, concerns
- An association in not an action[Rum91, 158], though there could be an underlying structural relationship[Rum91, 159]
- %T% The associated link between a client object and a server object is 'Communicates with'. What data that is actually exchanged is not described in the association. %ICON{wip}% is that for the dynamic model to provide?
Dependency:
Aggregation: %ICON{wip}% (Describe this exactly, so I know what it means) is just an association with extra connotations[Rum91,156], [Rum91,36].
Association role: [Rum91,34].
%ICON{wip}% It seems that this is mostly effective/relevant/used for Relational databases. Though this started out in the OOD book.
%ICON{wip}% What are the associations used for in real life???
Could it be that they turn into access functions?

An association is NOT; about the data being exchanged between objects. If you start thinking about what two objects exchange, then write it up for the (%ICON{wip}% dynamic model) and set this association as a 'communication' association. E.g. Communicates with.

Implementation

Association
Pointer: Most often associations are implemented as pointer when implemented in a program[Rum9,27]. A pointer is an attribute in one object; that contains an explicit reference to another object.
relation: in RDBMS an association is implemented as a relation. As either a reference or a Look Up Table(LUT)

Illustration

[Rum91, 28]

Process

For each object; find out how the object associates(relates to) with each of the other objects.
for each time there is a link/association between two objects, describe the nature of the association.
Illustrate the associations, using the ObjectDiagram.

Describe attributes for the objects, and the links between the objects

[Rum91, 161]

%ICON{wip}% Why do attributes ?, what are they good for?

Possibly to force you to think more about what is going on, to expand the domain knowledge
Possibly to get a better under standing of what data the objects reference,
An attribute is a property of the object or association [Rum91, 31].
Attributes are often nouns followed by possessive phrases[Rum91, 161].
Adjectives often represent specific enumerated attribute values.

Attribute Process

Don't do an exhaustive search for attributes at this point, just the important ones ;) [Rum91, 162].
Don't do do the attributes that are solely for implementation [Rum91, 162]
Associations can also have attributes.

Testing access paths

[Rum91,166].

Grouping into modules

Modules provide an intermediate unit of packaging objects.[Rum91,43].
A module is a set of objects that captures some logical subset of the entire model[Rum91,168].
There should be fewer links between modules(external links) than within modules(internal bindings) [Rum91,43].
The same object my be referenced in different modules.[Rum91,43].
See also sheet: [Rum91,43].
Tightly coupled objects should be grouped together.[Rum91,168].

Write the use cases

See template at: VaporWare.TemplateUseCase (Wid03)

Write the use cases for
How does one go into this whole thing of writing Use Cases, how is it selected?
Name: Descriptive name to identify Use Case
Description:
System:
Actor:
- Users:
- Other systems or applications:
- A device:
Flow:
Basic flow:
Alternative flows:
Pre-conditions:
Post-Conditions:
Invariens:
Other stakeholders:
Special requirements:
Extension points:
Open issues:

Dynamic model

Functional model

Tools for creating requirements

UseCase: Used for capturing process description. See also SIPOC
StoryCard:
Blitz: Prototyping etc.
Context model:
Documentation:
ProcessDescription: ProcessModel, perhaps Sipoc, could this bee seen as digitizing the process.
- FlowChart

Example

StoryCard.15 - The Middle layer must be able to return the TOT data in a distinctive way, for the client to be able to recognize it.

Identify the objects:
- Read the problem statement.
  - Data
  - Middle layer
  - Client
  - TableOfTable
- List what entities are involved
  - Data
  - TOT structure
  - Data wrapper; sql server/XML file.
  - Middle layer
  - client
  - client side presentation
- Identify the 'stakeholders'
- Core developer: Presenting/providing the TOT data through the middle layer.
- Client side developer: Accessing the TOT data through the middle layer.
- Object List:
  - Client
  - Midlayer
  - Database
  - Table
  - Data
Update dictionary:
Client: the data application that is retrieving the data. The client will be able to search, retrieve, update, add, delete.
Data: The data to actually be retrieved.
Middle layer: An abstraction layer between the client and the data. By using a middle layer, it is possible to automatically procide a consisten data access interface from the database definition file. Also the middle layer can be re-used by the client, for editing, data statistics etc. See also: Multitier_architecture
Table of Table (TOT): XML, a table is stored inside another table, rather than using a relation table to tie the two tables together. The TOT is used for XML files to make it easier to edit using a text editor, you would include the table structure where you need it, rather than setting up links.
- In the example here, Coloumn and PreConfiguredData are TOT.

<Table Id="" Name="">
  <Description></Description>
  <PageTitle></PageTitle>
  <KeyColoumnName></KeyColoumnName>
  <DisplayColoumnName></DisplayColoumnName>
  <DoList></DoList>
  <TableSection></TableSection>
  <Coloumn Name="">
    <Reference></Reference>
    <LookUpTable></LookUpTable>
    <InList></InList>
    <FieldText></FieldText>
    <Description></Description>
    <DataType></DataType>
    <Size></Size>
    <SqlOption>
      <Value></Value>
    </SqlOption>
  </Coloumn>
  <PreConfiguredData>
    <Id></Id>
    <DataOrder FieldOrder="" FieldName="">
      <Dummy></Dummy>
    </DataOrder>
    <Row>
      <Data>
        <FieldName></FieldName>
        <FieldValue></FieldValue>
      </Data>
    </Row>
  </PreConfiguredData>
</Table>

Describe the associations between the objects.: <img src="%ATTACHURLPATH%/object_diagram.png" alt="object_diagram.png" width='449' height='410' />
Attributes:
- ML
  - DB connection
  - table data arrays
- Client
UseCase:
Description: Reading the data from the database.
System or subsystem: Read operations.
- Others: Write, new, delete, connect to db, close connection.
Actor(s): Client
Flow of events:
- Basic flow:
  - Get list of tables
  - Get data for table
  - *** How do I handle the data TOT, refs etc.
- Alternat Flow:
Pre-conditions:
Post-conditions:
Other stakeholders:
Special requirements:
Extention points:
Open Issues:

Getting from the story card to the requirements

I know I want to support associations.

StoryCard

I want to support associations
- This originally started out as 'Table of Tables (TOT)'
Headline: Support table associations.
Description: Support associations between tables. And in xml; support table in table. While we are in here, also distinguish between local access and global access of associated data. e.g. Drop down boxes etc.
What is the purpose, what is the sought after outcome?
Priority: Critical
SOW:
2d Analysis: Analyze this, figure out how to do the analysis, what is in this.
Xd :
Document:
Implement:
Test:
Estimation:
Risks:
Type of work: New

Association Need

Type: Only one/one or more/zero or more/
LinkTo: Table to link to.
Creation: Local creation, or "global" creation.
Embed: Embed the association table in current table or not. Only used by XML. Not supported for sql.

What needs to come of this

Implemented in the structure
Implemented in the Midlayer
Implemented in the GUI
Described how to use it in the manuals, for developers and for end users.

So what is the next step?

Describe how association work?
Start writing some sort of high level requirement.
What is e.g. OneToMany? Does it mean many referenced instances or does it mean many types?
- So should OneToMany go into the dictionary? probably.
How do I reference the dictionary to provide a knowledge transfer? for other developers?
I need to end up with some usable code, that reflects the wishes of ScoreCard.
If it is an automation of a process then; do a UseCase.
Why do we need to associate data/tables?

Dictionary

Association: Any dependency between two or more classes. Used in the AnalysisPhase? to provide the ObjectModel?, with a link description. Another name for association is: 'relation', though this word isn't used here so as to avoid confusion[Rum91, 31].
single association: Exactly one.
ZeroOrMore:
OneOrMore: One to many.
Optional: None or one
Association type: Single/Optional/ZeroOrMore etc.

Requirement patterns

Patter name: Operations

Basic details

pattern manifestation:
owning domain:
related patterns (if any):
- This lists any other requirement patterns that apply to related situations. If it would be helpful, this item can also say a little about how the patterns relate to each other.
anticipated frequency of use:
pattern classification:
- E.g.: Functional: Yes; Performance: Yes
pattern author:

Pattern manifestation

The pattern's version number:
The date the pattern was last changed:
The requirements approach:
The customer organization (company name):
The requirements specification language: English.
Belongs to domain:
Applicability: Opreations...
- In what situations can the pattern be applied?
- And when can it not be applied?
Discussion:
- How do we write a requirement of this type? What does a requirement of this type need to consider?
Content:
- What must a requirement of this type say? What extra things might it say? This is the main substance of the pattern.

Template(s)

A starting point for writing a requirement of this type'or more than one if there are distinct alternative ways.

Example(s)

One or more representative requirement written using this pattern. Extra requirements What sorts of requirements often follow on from a requirement of this type? And what pervasive systemwide requirements might define something for all requirements of this type?

Considerations for development:
- Hints for software designers and engineers on how to implement a requirement of this type.
Considerations for testing:
- What do we need to bear in mind when deciding how to test this type of requirement?