Requirement Analysis

Team Lincoln

Jordan Miller, Muhammet Oguz Yakut, Arnold Perez, Shon Baby

What are requirements?

● Birds eye view○ An expression of desired behavior

● Typically starts from a customer/clients notion of what a system should do○ Understand the customers problem and needs

○ Designate what behavior is wanted

● Deals with:○ System’s states

○ Functions onto those states

● Does not focus on solution or implementation○ Unless specified by customer

Requirement creation

Types of requirements

1. Functional:○ Describes required behavior of activities

2. Non-functional/Quality:○ Describes characteristics that the system must possess

3. Design constraint:○ Design decision such as choice of platform or interface

○ Restricts set of solutions

4. Process constraint○ Restriction on the techniques or resources that can be used to build the system

Types of requirements cont.

● Functional

○ Functionality:

■ What will the system do?

■ When will this happen?

■ What type of computations or data

manipulations must be done

■ What are the appropriate reactions

to input/outputs

○ Data:

■ Format of input/output data

■ Is there data retention?

● Quality/non-functional

○ Performance

■ Constraints on speed, response

time, throughput

○ Usability

■ How easy is it to use/misuse

○ Security

■ Data/program isolation, access

control

○ Reliability

○ Maintainability

■ Correct errors or improve system

○ Precision and Accuracy

○ Time to delivery/Cost

■ Timetable for development

■ Limit on available money

Types of requirements cont.

● Design Constraints

○ Physical environment

■ Location of equipement

■ Restrictions based on location

● Temperature, humidity, size,

power, heating/cooling

■ Programming language constraints

○ Interfaces

■ Sources of input and output

■ Specific format of input/output data

■ Medium that the data must use

○ Users

■ Who will use the system

■ Multiple users

■ Skill level for each user

● Process constraints

○ Resources

■ Required materials, personal, or

other resources to build system

■ Skills of developers

○ Documentation

■ How much documentation is

needed

■ Format of documentation

● book/online

■ Audience of the documentation

○ Standards

Users and Developers perspective

Developer -> User

1. Don’t know what they want

2. Can’t articulate what they want

3. Unable to provide usable list of needs

4. Have to many politically motivated needs

5. Wants everything right away

6. Can't remain on schedule

7. Can’t prioritize needs

8. Unwilling to compromise

9. Refuses to take responsibility for system

10. Not committed to development projects

User -> Developer

1. Don’t understand operation needs

2. Can't translate needs into a proper system

3. Sets unrealistic standards for a requirement

4. Place too much emphasis on technicalities

5. Always late

6. Can’t respond quick to changing needs

7. Always over budget

8. Says “no” all the time

9. Try to tell “us” how to do our jobs

10. Asks for the user’s time and effect

Sources of requirements

● Client○ Has final say in what product does

● Customer (sometimes the client)○ Has certain goals for purchasing the system

● Users○ Understands current system and improvements for new system

● Domain experts○ Familiar with the problem that the system is automating/improving

● Market researchers (sometimes the customer)○ Conducted surveys for needs

● Lawyers and auditors○ Ensure system is following proper government, safety, or legal requirements

● Software Engineers○ Ensure that product is technically feasible, estimate cost/time needed

Documentation

2 needed documents:

1. Requirements definitiona. Complete list of everything the customer wants to achieve

b. Describe the entities in the environment that the system is interacting with

2. Requirements specificationa. Restates the requirements as a specification of how the system shall behave

b. Written completely in terms of the environment and the entities accessible by system

c. Creates a boundary of what can be monitored/controlled by the system

Project surveys

● 31% of software projects were canceled before completion in a 1994 survey

● In large companies only 9% of projects were delivered on time and within

budget○ 16% met those criteria in small companies

The takeaway?

Developers have trouble delivering the

right system on time and within budget.

Causes of failed projects

● Incomplete requirements (13.1%)

● Lack of user involvement (12.4%)

● Lack of resources (10.6%)

● Unrealistic expectations (9.9%)

● Lack of executive support (9.3%)

● Changing requirements and specifications(8.7%)

● Lack of planning (8.1%)

● System no longer needed (7.5%)

Cost of fixing a bug at different stages of the design project

● $1 to find and fix a requirements-based problem during the requirements

definition process.

● $5 to repair it during design

● $10 during the coding process

● $20 during unit testing

● $200 after delivery○ That’s a 20000% increase from the definition process

Characteristics

1. Are the requirements correct?

2. Are the requirements consistent?

a. Are there any conflicting requirements?

3. Are the requirements unambiguous?

a. Enough detail is required

4. Are the requirements complete?

a. Specifies required behavior and output for all possible

inputs in all possible states under all possible constraints

5. Are the requirements feasible?

a. Is there a solution that meets customer’s needs?

6. Is every requirement relevant?

a. Ensure that requirements does not restrict the developer

unnecessarily

7. Are the requirements testable?

8. Are the requirements traceable?

a. Organized and uniquely labeled for easy reference

MODELING NOTATIONS

• Engineering discipline has repeatable processes for developing safe and successful products.

• There exists a standard notation for modeling, documenting, and communicating decisions.

• Modeling helps understand the requirements (Teases us to what questions we should be asking).

• Seemingly an infinite amount of specification and design notations and methods

• Most are similar. There are fewer than 10 basic paradigms for expressing information about a

problem’s concepts, behavior, and properties.

• Modeling for requirements is slightly different from modeling for design.

• We model requirements in order to simplify the model and make it easier to read and

understand.

• We model designs in order to improve system quality (modularity, performance etc.)

ENTITY-RELATIONSHIP DIAGRAMS

• Used for representing conceptual models. Used early in the requirements phase.

• 3 constructs: objects (entities), attributes, relationship.

• Useful for modeling relationships between objects or the structure of an application.

• Entity (rectangles): Represents a collection

of objects. (Classes in C) Ex: Visitor, Coin.

• Relationship: Edges between 2 entities with

a diamond that specifies the relationship

type.

• Attribute: Annotation on the entity

describing data or properties associated

with it.

ENTITY-RELATIONSHIP DIAGRAMS

• Provide an overview of the problem to be addressed.

• Relatively stable when changes are made to requirements. Behavior may change, entities do not.

• Quite difficult to use in practice

• At what level of detail should the problem be modeled?

• Criteria for making decisions in this model:

• Does the choice result in a clearer description?

• Does a choice unnecessarily constrain design decisions?

UML CLASS DIAGRAMS

• An entity-relationship diagram used to document software specifications and designs.

• Uses ER notation with a little more complexity.

• Primarily used as design notation but can be used as a conceptual modeling notation to represent

entities in the problem to be modeled.

• Each box represents a class.

• Has a name, attributes, and a set of operations

• Imprecision is typical in early conceptual diagrams. Missing some attributes and operations.

• Idea is to provide enough attributes and operations so that anyone who reads it can grasp what the

class represents and its responsibilities.

UML CLASS DIAGRAMS

• Class-scope attribute: underlined attributes associated with

the class rather than a specific instance of the class.

• Class-scope operation: underlined operations that are

performed by the abstract class. (Not the instance of the class)

• Association: relationship between two class entities.

• Aggregate association: ”has-a” relationships. One class is a

property or element of another class. Drawn as a line with a

diamond on one end.

• Composition: special type of aggregation where instances of

the compound class are are physically constructed from

instances of the component class (e.g., a bike consists of

wheels, gears, pedals, and a handlebar.)

UML CLASS DIAGRAMS

• Generalization: association with a triangle on one end. “is-a”

relationship. Class at the triangle end of the association is the

parent class of the subclasses at the other end.

• Role names: label that describes the role an entity plays in the

association.

• Multiplicities: specify constraints on the number of entities

and links between associated entities.

• Association class: relates attributes and operations to an

association. Used to collect information that cannot be

attributed solely to one class in the association.

EVENT TRACES

• Notation paradigm used for describing a systems behavioral requirements.

• A graphical description of a sequence of events that are exchanged between real-world entities.

• Vertical lines represent timeline for a distinct entity. Time progresses from top to bottom.

• Horizontal Line represents an interaction between two entities.

• Trace: represents one of several possible behaviors. The image shows 2 traces.

EVENT TRACES

• Popular among developers and customers because traces have semantics that is relatively precise

(excluding timing issues).

• The simplicity of traces comes from decomposing the requirements into scenarios and considering

each scenario as a distinct trace.

• However, traces are not viable in practice for a complete description as the number of scenarios

can become increasingly overwhelming.

• Best used at the start of a project to come to a consensus on key requirements and help identify

important entities.

MESSAGE SEQUENCE CHART

• An enhanced even-trace notation including:

• Facilities for creating and destroying entities

• Specifying actions and timers

• Composing traces

• Messages depicted as arrows from one entity to another

• Dashed arrows are ”create” events that spawn a new entity.

• Actions (labeled rectangles) are invoked operations or changes to variable values.

• Conditions (labeled hexagons) are used to specify important states in an entity’s evolution.

STATE MACHINES

• Graphical description of all dialog between the system and its environment.

• State-machine notations are used to represent collections of event traces in a single model.

• State (Each node): represents a stable set of conditions that exist between occurrences.

• Transition (Each Edge): represents a change in behavior or condition due to the occurrence of an event.

• State machines are useful for specifying dynamic behavior and describing how it should change based on the history of events that have already occurred.

STATE MACHINES

• A path through the state machine, starting from the initial node is a trace.

• A state machine is deterministic if for every state and event there is a unique response.

• State machines specify the sequence of input and output events that the proposed system is expected to realize.

UML STATECHART DIAGRAMS

• An example of a state machine.

• Depicts the dynamic behavior of the objects in a UML class.

• UML diagrams give a big picture of problem in terms of entities and their relationships. They don’t explain how the entities behave.

• Statechart diagrams show how class instances should change state as objects interact with each other.

• A UML model is a collection of concurrently executing statecharts that communicate with each other.

• Superstates: a collection of states with common transitions. Used to unclutter diagrams.

UML STATECHART DIAGRAMS

• A superstate can comprise of multiple concurrent submachines, separated by dashed lines.

• Submachines are said to operate concurrently, in that the class instance can receive and respond to events to both submachines.

• A form of state transition notation that is used to model concurrent activities and their interactions.

• Circles in the net are places that represent activities or conditions.

• Transitions represented by bars.

• Arcs are directed arrows that connect a transition with its input places and output places.

• Tokens populate the places and act as enabling conditions for transitions.

• Arcs are assigned a weight that specifies how many tokens are removed from the input place when the transition fires.

• The nets marking is the distribution of tokens among places.

PETRI NETS

PETRI NETS

DATA-FLOW DIAGRAMS

• Models functionality and flow of data from one function to another.

• A process, represented by a bubble, is used to transform data.

• An arrow is used to represent data flow.

• Data Store: a formal repository or database of information. Represented by two parallel bars.

• Actors are entities that provide input data or receive the output results. Represented by rectangles.

DATA-FLOW DIAGRAMS

USE-CASE DIAGRAMS

• Similar to a top-level data-flow diagram that depicts observable, user-initiated functionality in terms of interactions between the system and its environment.

• Large box represents the system boundary. Figures outside portray the actors.

• Each oval inside the box is a use case that represents some major required functionality and its variants.

• Use cases are not meant to model all tasks that the system should provide.

• Each case encompasses several possible scenarios related to some usage of the system.

USE-CASE DIAGRAMS

FORMAL METHODS

• Unlike previous notational paradigms, formula methods or approaches are mathematically

based specifications and design techniques.

• Less ambiguous and have a more sophisticated analysis and verification.

• Some paradigms model requirements as collections of mathematical functions that map

inputs to output.

DECISION TABLES

• A tabular representation of functional specifications that map events to appropriate

responses.

• Informal because inputs and outputs can be written mathematically or naturally.

• Input event listed on the top and outputs listed on the bottom.

• Each column is a rule that maps conditions to results.

• Can result in very large tables. (2^n combinations)

• Easy to check if every condition has been considered.

• Can search table for patterns.

PARNAS TABLES

• Similar to decision tables. Each entry specifies an input condition case, or an output value.

• Unlike decision tables, inputs and outputs a parnas tables are purely mathematical.

• Internal entries in the table store the function results. So each one is a distinct case.

• Covers all possible combinations of conditions

FIRST ORDER AND TEMPORAL LOGIC

• Operational notations are notations that describe a problem or software in terms of its

behavior.

• A closed model is one that expresses all of the desired behaviors.

• Descriptive notations (such as logic) describe a problem or proposed solution in terms of

its properties or invariant behaviors.

• A logic consists of a language for expressing properties, plus a set of rules for deriving new

properties from the ones already stated.

FIRST ORDER AND TEMPORAL LOGIC

• First-order logic is the logic commonly used to express properties of software

requirements and is comprised of typed variables.

○ Does not say anything about how variables change value.

○ However the values change, the values always meet formulae constraints.

• Temporal logic introduces additional logical connectives which constrain how variables

can change over time.

○ Can express imminent changes.

○ Temporal logic represents varying behavior more succinctly.

Object Constraint Language

• A constraint language that is mathematically precise, and easy for nonmathematicians

(customers) to understand.

• Designed for expressing constraints on object models.

• Constraint on Patron says fines can not be negative.

• Publication constraint: all call numbers are unique.

Z

• A formal requirements specification language that structures theoretic definitions of

variables into a complete abstract-data-type model of a problem.

• Uses logic to express the pre- and post- conditions for each operation.

• Decomposes a specification into manageably sized modules called schemas.

• Schemas can specify:

• System state in terms of typed variables

• System’s initial state

• Operations

• Additionally, Z offers the precision of a mathematical notation and all its benefits such as

evaluating specifications using proofs.

PROTOTYPING REQUIREMENTS

• It is common for the customer to be uncertain about what exactly they want.

• Building prototypes for the customer to critique fleshes out the requirements.

○ What is missing? What can be improved? What needs to be changed?

• Two approaches to prototyping: Throwaway and Evolutionary

• Throwaway prototypes are developed to learn more about a problem or solution and

never intended to be part of the delivered software.

• Evolutionary Prototypes are developed to help answer questions and also intended to be

included as part of the final product.

• Both are called rapid prototyping as they involve building software to answer questions

about the requirements.

PROTOTYPING REQUIREMENTS

DOCUMENTING REQUIREMENTS

• Requirements must be documented throughout the creation process so they can be

referred to by us and the customers.

• Requirements definition: Requirements expressed in the customers terms.

1. Outline the general purpose and scope of the system.

1. Describe the background and the rationale behind the proposal for a new system.

1. Describe the essential characteristics of an acceptable solution.

1. Describe the environment in which the system will operate.

1. If customer has a proposal for solving the problem, we outline a description of the

proposal.

1. List any assumptions we make about how the environment behaves.

DOCUMENTING REQUIREMENTS

• Requirements specification: Covers the same ground as the definition, but from the eyes

of the developer.

1. Describe all the inputs and outputs in detail.

1. Restate the required functionality in terms of the interfaces’ inputs and outputs.

1. Devise a fit criteria for each of the customers quality requirements.

IEEE Standard

Standard by Institute of Electrical

and Electronic Engineers to

organize requirement

specifications by mode of

operation, function, feature,

category of user and so on.

Participants in the requirement process

● Customer○ Documentation of what the customer expects of the delivered system

○ Record of the requirements expressed in the customer’s terms

● Developers○ Requirements written in terms of the system’s interface

○ Description of what the developers are supposed to produce, written in sufficient detail to

distinguish between acceptable and unacceptable solutions

Validation and verification

● Requirements must meet customer needs

● Requirements documents serve as both as a contract between developers

and customers as to what the product entails.

● Both parties intent must be captured in the requirements documents and to

establish certainty validation of the requirements and verification of the

specification is required.

Requirement Reviews

● Representatives from both parties examine the requirements document

individually then meet to discuss identified problems.

● Whenever a problem is identified, the problem is documented and its cause it

determined

○ Requirement analysts are charged with the task of fixing the problem

Validation, verification and checking

Requirements validation checks if the requirement definition accurately reflects the

all the stakeholders’ needs (Building the right system)

Criteria for validating the requirements are:

Correct, Consistent, Unambiguous, complete, relevant, testable and traceable.

Verification checks one document or artifact confirms to another (Building the

system right)

Measuring requirements

● Focuses on product, process and resources

● Number of requirements can give a sense of scale on how large the

developed system is likely to be

● Number of changes to requirements and indicate some instability or

uncertainty

Measuring requirement readiness

● A rating scheme on requirement understanding can provide useful feedback

towards project completion○ This can be done by asking testers about their understanding and confidence to devise a

suitable test suite for each requirement

○ This can be used to determine whether the requirements are written at an appropriate level of

detail.

○ Rating each requirement on a scale 1 to 5. 1 being You the designer, understand this

requirement completely and 5 being you do not understand the requirement at all.

Specification language selection criteria

● Set of criteria for evaluating methods. These criteria were intended for evaluating techniques for specifying reactive systems.

● Applicability

○ Can the technique describe real-world problems and solutions in a natural and realistic way?

● Implementability

○ Can the specification be refined or translated easily into an implementation?

● Testability/simulation

○ Can the specification be used to test the implementation?

● Checkability

○ Are the specifications readable by non developers?

● Maintainability

○ Will the specification be useful in making changes to the system?

● Modularity

○ Does the method allow a large specification ot be decomposed into smaller parts that are easier to write and to understand?

● Level of abstraction/expressibility

○ How closely and expressively do objects, states and events in the language correspond to the actual objects, actions and conditions

in the problem domain?

Specification language selection criteria (cont.)

● Soundness

○ Does the language or do the tools facilitate checking for inconsistencies or ambiguities in the specification?

● Verifiability

○ Can we demonstrate formally the the specification satisfies the requirements?

● Runtime safety

○ Does the code degrade gracefully under unexpected runtime conditions?

● Tools maturity

○ Tool support, training and user base

● Looseness

○ Can the specification be incomplete or admit nondeterminism?

● Learning Curve

○ How quickly a user can learn technique concepts, syntax, semantics, and heuristics?

● Technique maturity

○ Technique certification or standardization and user base

● Data modeling

○ Is data modeling facilities and integrated part of the technique?

● Discipline

○ Does technique force users to write well-structured, understandable and well-behaved specifications?

UML and message sequence charts

The figure uses UML-style Message

sequence charts, in which entities whose

names are underlined represent object

instances, whereas entities whose

names are not underlined represent

abstract classes.

Purpose of MSC is to provide a trace

language for the specification and

description of the communication

behaviour of system components and

their environment by means of message

interchange

Falling Forward

In science you not only have to have the stomach for

failures, you actually have to enjoy the taste of it.Failures, one of the most hated events, are integral parts of life. For example, the

lion’s success rate of capturing its prey is only 7%, and evolution’s success rate is

a measly 1%!

Ariane-5 explosion was caused by the reuse of a section of code from Ariane-

4.The SRI functionality that continued after liftoff in Ariane-4 was not needed after

liftoff in Ariane-5. Measures taken during requirements analysis would have led to

a greater understanding of the differences between Ariane-4 and Ariane 5, and to

detecting the root cause of the error