SOFTWARE ENGINEERING

REQUIREMENTS ANALYSIS AND

SPECIFICATION

Saulius Ragaišis

saulius.ragaisis@mif.vu.lt

CSC2008 SE “Requirements Specifications”Learning Objectives:

• Apply key elements and common methods for elicitation and analysis to produce a set of software requirements for a medium-sized software system.

• Discuss the challenges of maintaining legacy software.

• Use a common, non-formal method to model and specify (in the form of a requirements specification document) the requirements for a medium-size software system.

• Conduct a review of a software requirements document using best practices to determine the quality of the document.

• Translate into natural language a software requirements specification (e.g., a software component contract) written in a formal specification language.

SYSTEM ENGINEERING

Definition

• A computer-based system is a set or arrangement of elements that are organized to accomplish some predefined goal by processing information.

System elements

• Software

• Hardware

• People

• Procedures

• Database

• Documentation

System modeling

• Define the processes that serve the needs of the view under consideration.

• Represent behavior of the processes and the assumptions on which the behavior is based.

• Explicitly define both exogenous and endogenous input to the model.

• Represent all linkages (including output) that will enable the engineer to better understand the view.

Restraining factors

• Assumptions

• Simplifications

• Limitations

• Constraints

• Preferences

Business process engineering

• A goal of BPE is to define architectures that will enable a business to use information effectively.

• The architectures must be analyzed and designed within the context of business objectives and goals:

– Data architecture

– Applications architecture

– Technology infrastructure

Product engineering

• The goal of product engineering is to translate the customer’s desire for a set of defined capabilities into a working product.

• To achieve this goal product engineering should derive:

– architecture encompasses 4 distinct system components: software, hardware, data (and databases), and people;

– infrastructure is established and includes the technology required to tie the components together and the information (e.g., documents) that is used to support the components.

Interesting reading

Cathleen Shamieh

Systems Engineering For Dummies, ® IBM Limited Edition

Wiley Publishing, Inc., 2011.

available for download

SOFTWARE REQUIREMENTS

ENGINEERING

What is it?

• Requirements engineering helps software engineers to better understand the problem they will work to solve.

• It encompasses the set of tasks that lead to an understanding of:

–what the business impact of the software will be,

–what the customer wants, and

–how end-users will interact with the software.

What are the steps?

• Inception - a task that defines the scope and nature of the problem to be solved

• Elicitation - a task that helps the customer to define what is required

• Elaboration - where basic requirements are refined and modified

• Negotiation - what are the priorities, what is essential, when it is required

• Specification

• Validation

• Management

What is the work product?

• The intent of the requirements engineering process is to provide all parties with a written understanding of the problem.

• This can be achieved though a number of work products:

– user scenarios,

– functions and features lists,

– analysis models, or

– specification.

Initiating RE process

• Identifying the stakeholders

• Recognizing multiple viewpoints

• Working towards collaboration

• Asking the first questions

Requirements elicitation

• Standish Group listed “Lack of User Input” as most common factor of challenged projects.

• Requirements Elicitation is the process of discovering the requirements for a system by communication with customers, system users and other stakeholders.

• Development teams have to take the initiative.

Difficulties in requirements elicitation

• Problems of scope.

• Problems of understanding.

• Problems of volatility.

Challenges of requirements elicitation

• “Yes, But” syndrome

• “Undiscovered Ruins” syndrome

• “User and Developer” syndrome

• “The sins of your predecessors” syndrome

“Yes, But” syndrome

• First time users see the system the first reaction is either, “wow this is so cool” or “Yes, but, hm, now that I see it, what about this…? Wouldn’t it be nice …?

• Users reaction is simply human nature.

• Need to employ techniques that get the “yes, buts” out early.

• Anticipate that there will be “yes, buts” and add time and resources to plan for feedback.

• Tends to be user interface centric, these tend to be the touch points of the system by the users.

“Undiscovered Ruins” syndrome

• Teams struggle with determining when they are done with requirements elicitation.– Is done when all the requirements are elicited or

have they found at least enough?

– Like asking an archeologist “how many undiscovered ruins are there?”

• First scope the requirements elicitation effort by defining the problem or problems that are to be solved with the system.

• Employ techniques that help find some of those ruins and have the stakeholders buy-into the requirements.

“User and the Developer” syndrome

• Users do not know what they want, or they know what they want but cannot articulate it.

• Users think they know what they want until developers give them what they said they wanted.

• Analysts think they understand user problems better than users do.

• Everybody believes everybody else is politically motivated.

• Recognize and appreciate the user as domain experts; try different techniques.

• Provide alternative elicitation techniques earlier; storyboard, role playing, prototypes, and so on.

• Put the analyst in the users place. Try role playing for an hour or a day.

• Yes, its part of human nature, so lets get on with the program.

Characteristic Response

“The sins of your predecessors” syndrome

• Like it or not your users (marketing) and developers remember what happened in the past.– Quality programs that promised things would be

different.– The last project where requirements were vague

and/or were delivered short of expectations.

• The team “unilaterally” cut important features out of the last release.

• Need to build trust, slowly. Do not over commit to features, schedule, or budget.

• Build success by delivering highest priority features early in the process.

Requirements elicitation guidelines

• Assess system feasibility• Be sensitive to organizational and political

considerations• Identify and consult system stakeholders• Record requirements sources• Use business concerns to drive requirements elicitation• Look for domain constraints• Record requirements rationale• Collect requirements from multiple viewpoints• Prototype poorly understood requirements• Use scenarios to elicit requirements• Define operational processes• Reuse requirements

Requirements elicitation techniques

• Interviewing and questionnaires

• Requirements workshops

• Braining storming and idea reduction

• Storyboards

• Use cases

• Role playing

• Prototyping

Interviewing

• Simple direct technique

• Context-free questions can help achieve bias-free interviews

• Then, it may be appropriate to search for undiscovered requirements by exploring solutions.

• Convergence on some common needs will initiate a “requirements repository” for use during the project.

• A questionnaire is no substitute for an interview.

Requirements workshop

• The requirements workshop is perhaps the most powerful technique for eliciting requirements.

• It gathers all key stakeholders together for a short but intensely focused period.

• The use of an outside facilitator experienced in requirements management can ensure the success of the workshop.

• Brainstorming is the most important part of the workshop.

Brainstorming

• Brainstorming involves both idea generation and idea reduction.

• The most creative, innovative ideas often result from combining, seemingly unrelated ideas.

• Various voting techniques may be used to prioritize the ideas created.

• Although live brainstorming is preferred, web-based brainstorming may be a viable alternative in some situations

Brainstorming (2)

• Do not allow criticism or debate.

• Let your imagination soar

• Generate as many ideas as possible

• Mutate and combine ideas

• Idea Reduction

– Pruning ideas that are not worthy of further discussion

– Grouping of similar ideas into one super topic

• Prioritize the remaining ideas

Storyboarding

• The purpose of storyboarding is to elicit early “Yes, But” reactions.

• Storyboards can be positive, active, or inactive.

• Storyboards identify the players, explain what happens to them, and describes how it happens.

• Make the storyboard sketchy, easy to modify, and unshippable.

• Storyboard early and often on every project with new or innovative content.

Use cases

• Use cases, like storyboards, identify the who, what, and how of system behavior.

• Use cases describe the interactions between a user and a system, focusing on what the system “does” for the user.

• The use case model describes the totality of the systems functional behavior.

• Early stages: After you have an overview of the use cases, perhaps only by a phrase apiece, expand 10% of them in detail.

• Weakness of use cases -- we miss the quality attributes.

Prototyping

• Prototyping is especially effective in addressing the “Yes, But” and the “Undiscovered Ruins” syndromes.

• A software requirements prototype is a partial implementation of a software system, built to help developers, users, and customers better understand system requirements.

• Prototype the “fuzzy” requirements: those that, although known or implied, are poorly defined and poorly understood.

Functional and non-functional requirements

IEEE definitions:Functional requirement - a requirement that specifies a function that a system/software system or its component must be capable of performing. These are software requirements that define behavior of the system, that is, the fundamental process or transformation that software and hardware components of the system perform on inputs to produce outputs.Nonfunctional requirement - a software requirement that describes not what the software will do, but how the software will do it, for example, software performance requirements, software external interface requirements, software design constraints, and software quality attributes. Nonfunctional requirements are difficult to test; therefore, they are usually evaluated subjectively.

Other definitions

Functional requirement (FR) defines a function of a software system or its component. A function is described as a set of inputs, the behavior, and outputs. FR may be calculations, technical details, data manipulation and processing and other specific functionality that define what a system is supposed to accomplish. Non-functional requirement (NFR) is a requirement that specifies criteria that can be used to judge the operation of a system, rather than specific behaviors. Other terms for NFR are "constraints", "quality attributes", "quality goals", "quality of service requirements" and "non-behavioral requirements".

Uncertainty Principle in SE

• Uncertainty is inherent and inevitable in software development processes and products.

Causes of uncertainty in requirements

• Incomplete knowledge

• Imprecise understanding of needs

• Differing needs among users

• Changing needs

REQUIREMENTS ANALYSIS MODELING

TECHNIQUES

Requirements analysis (RA)

• RA results in the specification of software’s operational characteristics; indicates software’s interface with other system elements; and establishes constraints that software must meet.

• RA provides the software designer with representation of information function, and behavior that can be translated to architectural, interface, and component level design.

• The analysis model and the requirements specification provide the developer and the customer with the means to asses quality once software is built.

Analysis rules of thumb

• The model should focus on requirements that are visible within the problem and business domain. The level of abstraction should be relatively high.

• Each element of the analysis model should add to an overall understanding of software requirements and provide insight into the information domain, function, and behavior of the system.

Analysis rules of thumb (2)

• Delay consideration of infrastructure and other non-functional models until design.

• Minimize coupling throughout the system.

• Be certain that the analysis model provides value to all stakeholders.

• Keep the model as simple as it can be.

Domain analysis

Analysis modeling approaches

• Structured analysis

considers data and the processes that transform the data as separate entities.

• Object-oriented analysis

focuses on the definition of classes and the manner in which they collaborate with one another to effect customer requirements.

Elements of the analysis model

• Scenario-based elements: use-cases - text, use-case

diagrams, activity diagrams, swim lane diagrams.

• Class-based elements: class diagrams, analysis

packages, CRC models, collaboration diagrams.

• Behavioral elements: state diagrams, sequence

diagrams.

• Flow-oriented elements: data flow diagrams, control

flow diagrams, processing narratives.

Data modeling concepts

• Data objects

• Data attributes

• Relationships

• Cardinality and modality

Flow-oriented modeling

• The level 0 data flow (context) diagram should depict the software/system as a single bubble.

• Primary input and output should be carefully noted.

• Refinement should begin by isolating candidate processes, data objects, and data stores to be represented at the next level.

• All arrows and bubbles should be labeled with meaningful names.

• Information flow continuity must be maintained from level to level.

• One bubble at a time should be refined.

Context DFD (example)

Level 1 DFD (example)

Other flow-oriented elements

• Control flow modeling

• Control specification (CSPEC)

• Process specification (PSPEC)

FORMAL SPECIFICATION TECHNIQUES

Formal methods

• Advantages

• Disadvantages

Definition

A method is formal if it has a sound mathematical basis, typically given by a formal specification language. This basis provides a means of precisely defining notions like consistency and completeness, and more relevantly, specification, implementation and correctness. [The Encyclopedia of Software Engineering]

Mathematical Fundamentals

• Relations, • Functions,• Logical expressions,• Quantifiers,• Types,• Sequences,• Tuples,• Propositional Logic,• Sets,• First-Order Logic,and etc.

Example: a block handler

Block handler is a part of the file system. Files are composed of blocks. Files will be created and deleted. The system should maintain unused (free) blocks and keep track of blocks in use. When blocks of deleted file are released, they are added to a queue of blocks waiting to be added to the reservoir of unused blocks.

State of block handler consists of the collection of free blocks, the collection of used blocks, and the queue of returned blocks.

Example: a block handler (2)

Data invariant is:• No block is marked as both used and unused.• All the sets of blocks in the queue are subsets of

the collection of used blocks.• No elements of the queue contain the same

block.• The collection of used and unused blocks is the

total collection of blocks.• The collection of unused blocks have no

duplicates.• The collection of used blocks have no duplicates.

Example: a block handler (3)

Operations:

• add() a collection of blocks to the end of the queue;

• remove() a collection of used blocks from the front of the queue and place them in the collection of unused blocks;

• check() whether the queue of blocks is empty.

Z specification language• Z is a model-based specification framework.

• The idea is to construct an abstract model of the system to be built. It is high level, idealized, does not detail with implementation specifics.

• The model consists of descriptions of system state space and system operations.

• State space is the set of all states that the system could be.

• The state describes the value of each variable (and memory location).

Z schemas

• Z schema is a 2-dimensional graphical notation for describing state spaces and operations.

• A vertical-form schema is either of the form

or of the form

SchemaName

Declarations

Predicate 1 ;…; Predicate n

SchemaName

Declarations

Other Z notationsSets:

S : P X S is declared as a set of XS.

x S x is a member of S.

x S x is not a member of S.

S T S is a subset of T: Every member of S is also in T.

S T The union of S and T: It contains every member of S or T or both.

S T The intersection of S and T: It contains every member of both S and T.

S \ T The difference of S and T: It contains every member of S except those also in T.

Ø Empty set: It contains no members.

{x} Singleton set: It contains just x.

N The set of natural numbers 0, 1, 2, …

S: F X S is declared as a finite set of XS.

max (S) The maximum of the nonempty set of numbers S.

Functions:

f:X Y f is declared as a partial injection from X to Y.

dom f The domain of f: the set of values x for which f(x) is defined.

ran f The range of f: the set of values taken by f(x) as x varies over the domain of f.

f {x y} A function that agrees with f except that x is mapped to y.

{x} f A function like f, except that x is removed from its domain.

Logic:

P Λ Q P and Q: It is true if both P and Q are true.

P Q P implies Q: It is true if either Q is true or P is false.

θ S' = θ S No components of schema S change in an operation.

Example using Z

State of block handler and data invariant:

BlockHandler

used, free : P BLOCKS

BlockQueue : seq P BLOCKS

used free = Ø Λ used free = AllBlocks Λ

i : dom BlockQueue · BlockQueue i used Λ

j i , : d om BlockQueue · i | j => BlockQueue i BlockQueue j = Ø

Example using Z: operations

RemoveBlocks

∆ BlockHandler

# BlockQueue >0,

used' = used \ head BlockQueue Λ free' = free BlockQueue Λ BlockQueue ' = tail BlockQueue

AddBlocks

∆ BlockHandler

Ablocks? : BLOCKS

Ablocks? used

BlockQueue ' = BlockQueue . ? Ablocks Λ

used' = used Λ free' = free

Object Constraint Language (OCL)

• OCL is a formal notation used in UML diagrams for more precise specification of their elements.

• OCL expressions are called constraints; implementation should ensure that constraints always remains true.

• Expressions involve operators on operating objects but their result is Boolean.

• The object self is the element of UML diagram in the context of which OCL expression is being evaluated.

Key OCL notations

OCL notation Meaning

x.y Obtain the property y of object x. A property can be an attribute,

the set of objects at the end of an association, the result of

evaluating an operation, or other things depending on the type of

UML diagram. If x is a Set, then y is applied to every element of

x; the results are collected into a new Set.

c–>f() Apply the built-in OCL operation f to Collection c itself (as

opposed to each of the objects in c). Examples of built-in

operations are listed below.

and, or, = <> Logical and, logical or, equals, not-equals.

p implies q True if either q is true or p is false.

Sample of Operations Specific to Sets

s1–>intersection(s2) The set of those elements found in s1 and also

in s2.

s1–>union(s2) The set of those elements found in either s1 or

s2.

s1–>excluding(x) The set s1 with object x omitted.

Key OCL notations (2)

Sample of Operations on Collections (including Sets and Sequences)

c–>size() The number of elements in Collection c.

c–>isEmpty() True if c has no elements, false otherwise.

c1–>includesAll(c2) True if every element of c2 is found in c1.

c1–>excludesAll(c2) True if no element of c2 is found in c1.

c–>forAll(elem | boolexpr) True if boolexpr is true when applied to every

element of c. As an element is being evaluated,

it is bound to the variable elem, which can be

used in boolexpr. This implements universal

quantification, discussed earlier.

c–>forAll(elem1, elem2 | boolexpr) Same as above, except that boolexpr is

evaluated for every possible pair of elements

taken from c, including cases where the pair

consists of the same element.

c–>isUnique(elem | expr) True if expr evaluates to a different value when

applied to every element of c.

Sample Operation Specific to Sequences seq–>first() The object that is the first element in the

sequence seq.

Example using OCL

• No block will be marked as both used and unused:context BlockHandler inv:

(self.used -> intersection(self.free)) -> isEmpty()

• All the sets of blocks in the queue are subsets of the collection of used blocks:

context BlockHandler inv:

blockQueue -> forAll(aBlockSet | used -> includesALL)aBlockSet))

• No elements of the queue contain the same blockcontext BlockHandler inv:

blockQueue -> forAll(blockSet1, blockSet2 |

blockSet1 <> blockSet2 implies

blockSet1.elements.number -> excludesALL(blockSet1.elements.number))

…

SOFTWARE COMPONENT CONTRACT

ContractContract is a collection of assertions that describe precisely what each feature of the component does and does not do.

Levels of contract:

1. Basic, or syntactic, contracts are required simply to make the system work.

2. Behavioral contracts improve the level of confidence in a sequential context.

3. Synchronization contracts improve the level of confidence in distributed or concurrency context.

4. Quality-of-service contracts quantify quality of service and is usually negotiable.

Basic contracts

Interface definition language (IDL), as well as typed object-based or object-oriented languages, let specify:

• the operations a component can perform,

• the input and output parameters each component requires, and

• the possible exceptions that might be raised during operation.

Behavioral contracts

First implemented under the name design by contract in the Eiffel language. Also they can be found in UML as the Object Constraint Language (OCL).

The key assertions in the design by contract technique are of three types:

• invariants,

• preconditions, and

• postconditions.

Invariant

Invariant is a constraint attached to type that must be held true for all instances of the type whenever an operation is not being performed on the instance. For example, an invariant might state that

the value of some attribute is always greater than zero.

In the case of component methods, the invariants can be attached to an interface to specify properties of the component objects that implement the interface.

Preconditions and postconditions

• Preconditions and postconditions are assertions attached to an operation of a type.

• Precondition expresses requirements that any call of the operation must satisfy if it is to be correct.

• Postcondition expresses properties that are ensured in return by the execution of the call.

• For example, an operation to delete a record from a collection might have a precondition requiring that a record with that key exists and a postcondition requiring that it no longer be an element of the collection.

Synchronization contracts

• The aim of such contract is to describe the dependencies between services provided by a component, such as sequence, parallelism, or shuffle.

• They could be expressed by attaching to components special elements called synchronization policies.

• Java provides a stripped-down version of synchronization through the keyword “synchronized”.

Quality-of-service contracts

Common examples:

• maximum response delay;

• average response;

• quality of the result, expressed as precision;

• result throughput for multiobject answers such as data streams.

What we have learned?

• Main concepts of requirements analysis and specification

• Overview of structured analysis and formal methods

Next (more detailed)

• Object-oriented analysis

QUESTIONS?