Please enable JavaScript.
Coggle requires JavaScript to display documents.
ESTABLISHING PROJECT FOUNDATIONS (Requirement engineering (Requirement…
ESTABLISHING PROJECT
FOUNDATIONS
Requirement engineering
Requirement development
activities
analysis
: translating user needs, customer expectations, and acquirer ’ s conditions into technical requirements for hardware, software, and people elements
allocation
: allocating requirements to the hardware, software, and people elements of the system
specification
: documenting technical requirements in standard notations and formats; recorded in a Technical Specifications document
verification
: determining that the Technical Specifications are
correct
,
complete
, and
consistent
with respect to the Concept of Operations,
traceability matrix
is often used to determine
negotiation
: give - and - take discussions among stakeholders to achieve consensus views
acceptance
: commitment to a requirements baseline, by all involved stakeholders, that accounts for the constraints of schedule, budget, resources, technology, and risk factors
elicitation
examples of techniques
brainstorming
questionnaires
introspection
:information_source: understanding user needs, customer expectations, and acquirer ’ s conditions and documenting them in a
Concept of Operations
document
Taxonomy of product requirements
The Concept of Operations (ConOps)
:information_source: The document in which operational requirements are recorded
content
an operational vision for the proposed system
modes of operation for the proposed system
user classes and characteristics
kinds of and characteristics of operations personnel
operational requirements
operational scenarios
prioritized system features and quality attributes
impact of the proposed system on the development, operational, and maintenance environments
needs and expectations that motivate development of a new system or modification of an existing system
provides validation criteria
Operational requirements
Categories
Desirable
: add value to the system
Optional
Essential
: features and quality attributes that must be
provided if the system is to satisfy basic user needs and customer expectations.
:pencil2: operational requirements must be simple declarative statement that contains no “ ands, ” “ ors, ” “ ifs, ” or “ buts. ”
:warning: initial project plan must provide sufficient schedule, budget & resources to implement the essential reqs and as many desirable reqs as possible
include
quality attributes
design constraints
operational features
continue to grow over time either
decomposition of OR
changes to the OR by the customer, either if it is accompanied with the corresponding adjustment (good) or not (bad, "
scope creep
")
requirements problems and examples
Requirement management
:information_source: managing subsequent changes to the operational requirements and technical specifications and keeping those changes in balance with schedule, budget, resources, technology and other project factors.
primary mechanisms
Change control boards (CCB)
Process flow for a software development CCB
:information_source: consists of one or more individuals who have the authority to make changes to the requirements and make the corresponding adjustments to schedule, budget, resources, and/or technology as necessary.
relies on
Configuration management process (CM)
tasks
approves initial baselines of those work products
provide configuration audits
identifies the work products to be placed under version control
analyzes change trends and
responds as appropriate; and
Trend report for baselined requirements
evaluates proposed changes to baselines, approves, defers, or denies change proposals;
adjusts schedule, budget, resources, and technology to accommodate approved changes;
schedules and tracks changes to completion;
has the authority to accomplish these tasks
Baseline
:information_source:work products that are placed under version control and may not be further modified with the approval of a CCB
can be only changed
because of a requested change to the work product (
change request CR
)
because of a defect in the work product. (
problem reports PR
)
Each change to requirements must be accompanied by an
impact analysis
Configuration management (CM)
:information_source:
primary mechanism of requirement maangement
includes
change control board (CCB)
status reporting
version control
Process-flow of requirement engineering
Requirements Verification
determining that each operational requirement and each of the technical specifications is externally complete, consistent, and correct with respect to the other requirements and related work products such as test plans and test scenarios
traceability
is the primary technique
determining the internal completeness, correctness, and consistency of each of operational requirement and each technical specification;
using
analysis
,
reviews
, and
walkthroughs
Technical Specifications
Documenting Technical Specifications
Categories
derived requirements
:information_source: requirements for system features and quality attributes that are not visible to users but are necessary to support the operational requirements.
:question: why we use them?
decompose high - level operational requirements into detailed technical specifications
provide additional capabilities needed to satisfy operational requirements.
design goals
:information_source: operational requirements that have not yet been, or cannot be, translated into objectively stated technical specifications
:information_source: vague, imprecise, and/or ambiguous operational requirements
:warning: must not be accepted as binding requirements
Each design goal should be examined for possible translation into one of the other three categories
primary requirements
:information_source: operational features that have been translated into objectively stated specifications
include
functional requirements
&
quality requirements
design constraints
a design decision stated in the requirements and for which no flexibility
in design or implementation is allowed
examples
required interface
operations system must not do
each design constraint must
be identified as such
have their necessity justified
provide flexibility, if any
be restated in an objective manner
notes
Correspondence between ConOps & TS docs must be established,
Traceability matrices
are often used for this purpose
some OR do not have corresponding PR, either because the translating process isn't completed or that the OR is a design goal
:warning: if an operational requirement (OR) can be translated to more than one primary requirement (PR), it (the OR) should be decomposed so that each OR can be translated to one & only one PR
Requirements analysis
:information_source: clarifying operational requirements and restating them in terms that provide an objective criteria for v&v (making them technical specifications)
other informations
Project starting condition
: the perceived benefits, determined by some criteria, must outweigh the estimated cost of a project.
Project foundations
are derived from
Directives and Constraints from managers.
Requirements and Constraints from the customer
PROCESS FOUNDATIONS
The Contractual Agreement
types
formal
characteristics
includes (in addition)
price
• fixed price,
should include a contingency reserve in budget & schedule
• cost plus incentive fee
• cost plus fixed fee
• time and materials
payment schedule
rights in data
consequences of failure to satisfy the contractual terms
Only technical requirements must be binding
, the contract must contain a caveat that operational requirements are not binding and that technical specifications based on the operational requirements will be negotiated and accepted by acquirer and supplier.
include legally enforceable consequences to both parties if either party should violate the terms of the contract
:information_source: a
legal contract
between your organization and the acquirer ’ s organization, document in a
Statement of Work (SOW)
informal
:information_source: a
statement of understanding
between you, the project manager, and an
internal
customer., documented in
Memos Of Understanding (MOUs)
includes
scope of work
deliverable work products
delivery date(s)
customer/user and developer join review schedule
change request procedures
development constraints
product acceptance criteria (objective)
additional items, as appropriate
:information_source:
a contract
is a statement of understanding between two parties
Specifying the Scope of Your Project
using product foundations (operational requirements, system requirements, design constraints, and software requirements)
Foundation elements of software projects
Some organizations use project authorization forms (sometimes called “ project work orders ” or “project charters ” ) to officially launch a software project. project work orders or project charters should include the MOU or SOW
