MODULE 3

WORKFLOW OF SOFTWARE LIFECYCLE

Requirement

• A requirement is a statement describing either 1) an aspect of what the proposed system must do, or 2) a constraint on the system’s development.

• In either case, it must contribute in some way towards adequately solving the customer’s problem; the set of requirements as a whole represents a negotiated agreement among all stakeholders.

Requirement Workflow• Requirements engineering provides the appropriate

mechanism for understanding what the customer wants, analyzing need, assessing feasibility, negotiating a reasonable solution, specifying the solution unambiguously, validating the specification, and managing the requirements as they are transformed into an operational system

• The requirements engineering process can be described in five distinct steps– requirements elicitation– requirements analysis and negotiation– requirements specification– system modeling– requirements validation– requirements management

Types of requirements

• Requirements can be divided into four major types: functional, quality, platform and process.

• Requirements documents normally include at least the first two types.

NOTE

• Non-functional requirements• Quality, platform and process requirements

used to be collectively called non-functional requirements.

• However, that term has fallen into disfavor and therefore is not used.

Functional requirements

• Functional requirements describe what the system should do; in other words, they describe the services provided for the users and for other systems.

• The functional requirements should include • 1) everything that a user of the system would need to know

regarding what the system does, and • 2) everything that would concern any other system that has

to interface to this system.

The functional requirements can be further categorized as follows:• What inputs the system should accept, and under what conditions.

– This includes data and commands both from the users and from other systems.

• What outputs the system should produce, and under what conditions. – Outputs can be to the screen or printed. – They can also be transmitted to other systems, such as special I/O

devices, clients or servers.• What data the system should store that other systems might use.

– This is a special kind of output that will eventually become an input to other systems.

– Data which is stored for the exclusive use of this system (e.g. the specifics of a file format used to temporarily back up some data) can be ignored until the design stage.

• What computations the system should perform. • The computations should be described at a level that all the readers

can understand. • For example, you would describe a sorting process by saying that the

result is to be ordered in ascending sequence according to the account number. You would not normally specify the particular algorithm to be used.

• The timing and synchronization of the above. • Not all systems involve timing and synchronization – this category of

functional requirements is of most importance in hard real-time systems that do such things as control hardware devices (e.g. telecommunications systems, systems that control power plants or factories, and systems that run automobiles and airplanes).

• An individual requirement often covers more than one of the above categories.

• For example, the requirements for a word processor might say, ‘when the user selects “word count”, the system displays a dialog box listing the number of characters, words, sentences, lines, paragraphs, pages, and words per sentence in the current document.’

• This requirement clearly describes input (selecting ‘word count’), output (what is displayed) and computation (counting all the necessary information, and computing the average words per sentence).

Quality requirements• Quality requirements ensure the system possesses quality attributes such

as : usability, efficiency, reliability, maintainability and reusability. • These requirements constrain the design to meet specified levels of

quality.• The following are some of the main categories of quality requirements. Response time• For systems that process a lot of data or use a network extensively, you

should require that the system gives results or feedback to the user in a certain minimum time.

• For example, you might write that a result must be calculated in less than three seconds, or that feedback about the progress of a search must appear within one second.

• However, that for hard real-time systems, response time requirements should be considered to be functional – the system would not work unless they are adhered to.

Throughput• For number-crunching programs that may take hours, or for servers that

continually respond to client requests, it is a good idea to specify throughput, in terms of computations or transactions per minute.

Resource usage• For systems that use non-trivial amounts of such resources as memory

and network bandwidth, you should specify the maximum amount of these resources that the system will consume.

• This allows others to plan hardware upgrades.• For example, you could specify that no more than 50 MB of memory is to

be used by the system, and that the system must consume less than 10% of the CPU’s time when run on a 1.8GHz machine under a certain operating system.

Reliability• Reliability is measured as the average amount of time between failures or

the probability of a failure in a given period. • It is a good idea to set strong but realistic targets for this. For example,

you might specify that a continuously running server must not suffer more than one failure in six months period.

• It is necessary to define what you mean by a failure: normally it means much more than just crashes; failures normally include any difficulties users have getting their work done which are attributable to defects.

Availability• Availability measures the amount of time that a server is running and

available to respond to users. • As with reliability, you should set a target for this. For example, you might

specify that a server must be available over 99% of the time, and that no period of downtime may exceed 1 minute.

• Telecommunications systems have very rigorous availability criteria: for example, you might specify that such a system must not be down more than 10 minutes in its 20-year life-span.

Recovery from failure. • Requirements in this category constrain the allowed impact of a failure. • If the hardware or software crashes, or the power fails, then the system

will be able to recover within a certain amount of time, and with a certain minimal loss of data.

• For example, the requirements for a word processor might state: ‘the system will allow users to continue their work after a failure with the loss of no more than 20 words of typing or 20 formatting commands.’

• But the detailed procedure for recovery from failure is a functional requirement.

Allowances for maintainability and enhancement• In order to ensure that the system can be adapted in the future, you

should describe changes that are anticipated for subsequent releases. • This constrains design and improves quality without adding explicit new

functional requirements.

Allowances for reusability. • Similarly to the previous category, it is desirable in many cases to specify

that a certain percentage of the system, e.g. 40%, measured in terms of lines of code, must be designed generically so that it can be reused.

Platform requirements

• This type of requirement constrains the environment and technology of the system:

Computing platform• It is normally important to make it clear what hardware and operating

system the software must be able to work on. • Such requirements specify the least powerful platforms and declare that it

must work on anything more recent or more powerful. • For example, you might declare that certain software must run on any

computer operating under Mac OS X version 10.2 or MS-Windows 98 or higher, with 128 MB of RAM or more, and 100 MB of free disk space.

Technology to be used. • While it is wise to give the designers as much flexibility as possible in

choosing how to implement the system, sometimes constraints must be imposed.

• Common examples are to specify the programming language or database system.

• Such requirements are normally stated to ensure that all systems in an organization use the same technology – this reduces the need to train people in different technologies.

• The company might have also spent considerable money on a certain technology and wants to get the best value for that money.

Process requirements

• The final type of requirements constrains the project plan and development methods:

Development process (methodology) to be used. • In order to ensure quality, some requirements documents specify that

certain processes be followed; for example, particular approaches to testing.

• The details of the process should not be included in the requirements; instead a reference should be made to other documents that describe the process.

Cost and delivery date. • These are important constraints. • However, they are usually not placed in the requirements document, but

are found in the contract for the system or are left to a separate project plan document.

Requirements Elicitation

• It certainly seems simple enough—ask the customer, the users, and others what the objectives for the system or product are, what is to be accomplished, how the system or product fits into the needs of the business, and finally, how the system or product is to be used on a day-to-day basis.

• But it isn’t simple—it’s very hard.• A number of problems are identified that help us

understand why requirements elicitation is difficult:

• Problems of scope– The boundary of the system is ill-defined or the customers/

users specify unnecessary technical detail that may confuse, rather than clarify, overall system objectives.

• Problems of understanding– The customers/users are not completely sure of what is

needed, have a poor understanding of the capabilities and limitations of their computing environment, don’t have a full understanding of the problem domain, have trouble communicating needs to the system engineer, omit information that is believed to be “obvious,” specify requirements that conflict with the needs of other customers/users, or specify requirements that are ambiguous or untestable.

• Problems of volatility. – The requirements change over time.

• To help overcome these problems, system engineers must approach the requirements gathering activity in an organized manner.

• A set of detailed guidelines for requirements elicitation, which are summarized in the following steps:– Assess the business and technical feasibility for the proposed system.– Identify the people who will help specify requirements and understand their

organizational bias.– Define the technical environment (e.g., computing architecture, operating– system, telecommunications needs) into which the system or product will be– placed.– Identify “domain constraints” (i.e., characteristics of the business environment– specific to the application domain) that limit the functionality or performance– of the system or product to be built.– Define one or more requirements elicitation methods (e.g., interviews, focus

groups, team meetings).– Solicit participation from many people so that requirements are defined from

different points of view; be sure to identify the rationale for each requirement that is recorded.

– Identify ambiguous requirements as candidates for prototyping.– Create usage scenarios to help customers/users better identify key

requirements.

• The work products produced as a consequence of the requirements elicitation activity will vary depending on the size of the system or product to be built.

• For most systems, the work products include• A statement of need and feasibility.• A bounded statement of scope for the system or product.• A list of customers, users, and other stakeholders who

participated in the requirements elicitation activity.• A description of the system’s technical environment.• A list of requirements (preferably organized by function) and

the domain constraints that apply to each. • A set of usage scenarios that provide insight into the use of the

system or product under different operating conditions.• Any prototypes developed to better define requirements.

• Each of these work products is reviewed by all people who have participated in the requirements elicitation.

Requirement Elicitation (Gathering) Techniques (10 Marks)

1. Observation2. Interviewing3. Brainstorming4. Prototyping

• The first gathering technique, observation, is used to obtain subtle information that stakeholders may not think of telling you.

• The next three, interviewing, brainstorming and prototyping, are complementary techniques for actively asking for the opinions and knowledge of stakeholders as well as forcing the stakeholders to stretch their minds.

• Users participate in all four of these techniques, therefore they feel personally involved in the project.

• This sense of involvement means that they will more readily accept the final system.

Observation

• You can read documents and discuss requirements extensively with users, but often only the process of observing the users at work will bring to light subtle details that you might otherwise miss.

• In its simplest form, observation means taking a notebook and ‘shadowing’ important potential users as they do their work, writing down everything they do.

• You can also ask users to talk as they work, explaining what they are doing.

• In another variation, you can videotape the session so that you can analyze it in more detail later.

Interviewing

• Interviewing is a widely used technique. • However, a well-conducted series of interviews can elicit much more

information than poorly planned ad-hoc interviews.• Firstly, plan to have as many members of the software engineering team• interview as many stakeholders as possible. • Consider going beyond stakeholders, talking to users of competing

products, marketing personnel, and people involved with other systems that may interact in any way with the proposed system.

• Spread out the interviews over time, and allow yourself several hours for each interview, even if you do not expect to use that much time.

Brainstorming

• Brainstorming is an effective way to gather information from a group of people.

• The general idea is that the group sits around a table and discusses some topic with the goal of generating ideas.

• However, as with interviews, adding some structure to the brainstorming process can help elicit a larger amount of information.

• One of the keys to success is arranging for the brainstorming session to be led, or moderated, by somebody trained in the process.

Prototyping

• A prototype is a program that is rapidly implemented and contains only a small part of the anticipated functionality of a complete system.

• Its purpose is to gather requirements by allowing software engineers to obtain early feedback about their ideas.

• The simplest kind of prototype is a paper prototype of the user interface.• This is a set of pictures of the system that are shown to customers and

users in sequence, to explain what would happen when the system runs. • It can often be a very powerful tool for eliciting ideas and feedback, and

requires very little effort to create.• Because paper prototypes are easy to create, they are ideal for parallel

development. • In parallel development, several software engineers independently create

their own view of the system – the resulting prototypes are then evaluated and the best features of each become part of the system’s requirements.

• The most common type of prototype is a ‘mock-up’ of the system’s user interface, created using a rapid prototyping language.

• Rapid prototyping languages allows you to create code very quickly in order to display the important parts of a user interface.

• However, they have various weaknesses that limit their usefulness for creating the final version of complex systems.

• The weaknesses include inefficiency, and limitations on your ability to create robust and flexible designs.

Requirements Analysis and Negotiation• Once requirements have been gathered, the work products

noted earlier form the basis for requirements analysis. • Analysis categorizes requirements and organizes them into

related subsets; explores each requirement in relationship to others; examines requirements for consistency, omissions, and ambiguity; and ranks requirements based on the needs of customers/users.

• As the requirements analysis activity commences, the following questions are asked and answered:• Is each requirement consistent with the overall objective for

the system/product?• Have all requirements been specified at the proper level of

abstraction? That is, do some requirements provide a level of technical detail that is inappropriate at this stage?

• Is the requirement really necessary or does it represent an add-on feature that may not be essential to the objective of the system?

• Is each requirement bounded and unambiguous(clear)?• Does each requirement have attribution? That is, is a source

(generally, a specific individual) noted for each requirement?• Do any requirements conflict with other requirements?• Is each requirement achievable in the technical environment that

will house the system or product?• Is each requirement testable, once implemented?

• It isn’t unusual for customers and users to ask for more than can be achieved, given limited business resources.

• It also is relatively common for different customers or users to propose conflicting requirements, arguing that their version is “essential for our special needs.”

• The system engineer must reconcile these conflicts through a process of negotiation.

• Customers, users and stakeholders are asked to rank requirements and then discuss conflicts in priority.

• Risks associated with each requirement are identified and analyzed.

• Rough estimates of development effort are made and used to assess the impact of each requirement on project cost and delivery time.

• Using an iterative approach, requirements are eliminated, combined, and/or modified so that each party achieves some measure of satisfaction.

Requirements Specification• A specification can be a written document, a graphical model,

a formal mathematical model, a collection of usage scenarios, a prototype, or any combination of these.

• The System Specification is the final work product produced by the system and requirements engineer.

• It serves as the foundation for hardware engineering, software engineering, database engineering, and human engineering.

• It describes the function and performance of a computer-based system and the constraints that will govern its development.

• The System Specification also describes the information (data and control) that is input to and output from the system.

System Modeling

• It is important to evaluate the system’s components in relationship to one another, to determine how requirements fit into this picture, and to assess the “aesthetics” of the system as it has been formed.

Requirements Validation• The work products produced as a consequence of requirements

engineering (a system specification and related information) are assessed for quality during a validation step.

• Requirements validation examines the specification to ensure that all system requirements have been stated unambiguously; that inconsistencies, omissions, and errors have been detected and corrected; and that the work products conform to the standards established for the process, the project, and the product.

• The primary requirements validation mechanism is the formal technical review(FTR).

• The review team includes system engineers, customers, users, and other stakeholders who examine the system specification looking for errors in content or interpretation, areas where clarification may be required, missing information, inconsistencies (a major problem when large products or systems are engineered), conflicting requirements, or unrealistic (unachievable) requirements.

• Although the requirements validation review can be conducted in any manner that results in the discovery of requirements errors, it is useful to examine each requirement against a set of checklist questions.

• The following questions represent a small subset of those that might be asked:– Are requirements stated clearly? Can they be misinterpreted?– Is the source (e.g., a person, a regulation, a document) of the

requirement identified? Has the final statement of the requirement been examined by or against the original source?

– Is the requirement bounded in quantitative terms?– What other requirements relate to this requirement? Are they clearly

noted via a cross-reference matrix or other mechanism?– Does the requirement violate any domain constraints?– Is the requirement testable? If so, can we specify tests (sometimes

called validation criteria) to exercise the requirement?– Is the requirement traceable to any system model that has been

created?– Is the requirement traceable to overall system/product objectives?

– Is the system specification structured in a way that leads to easy understanding, easy reference, and easy translation into more technical work products?

– Has an index for the specification been created?– Have requirements associated with system performance, behavior,

and operational characteristics been clearly stated? What requirements appear to be implicit?

• Checklist questions like these help ensure that the validation team has done everything possible to conduct a thorough review of each requirement.

Requirements Management

• Requirements management is a set of activities that help the project team to identify, control, and track requirements and changes to requirements at any time as the project proceeds.

• Many of these activities are identical to the software configuration management techniques

Design Workflow

System Design Concept- Cohesion & Coupling

COHESION

• The cohesion principle is an extension of the divide and conquer principle – divide and conquer simply says to divide things up into smaller chunks.

• Cohesion says to do it intelligently: i.e., divide things up, but keep things together that belong together.

• A subsystem or module has high cohesion if it keeps together things that are related to each other, and keeps out other things.

• This makes the system as a whole easier to understand and change.• Listed below are several important types of cohesion that designers

should try to achieve. • Table summarizes these types of cohesion, starting with the most

desirable.

40

Functional cohesion • This is achieved when all the code that computes

a particular result is kept together - and everything else is kept out – i.e. when a module only performs a single

computation, and returns a result, without having side-effects.

– Benefits to the system:• Easier to understand• More reusable• Easier to replace

– Modules that update a database, create a new file or interact with the user are not functionally cohesive

41

Layer cohesion• All the facilities for providing or accessing a set of related services are kept

together, and everything else is kept out – The layers should form a hierarchy

• Higher layers can access services of lower layers, • Lower layers do not access higher layers

– The set of procedures through which a layer provides its services is the application programming interface (API)

– You can replace a layer without having any impact on the other layers• You just replicate the API

42

Example of the use of layers

43

Communicational cohesion• All the modules that access or manipulate

certain data are kept together (e.g. in the same class) - and everything else is kept out – A class would have good communicational

cohesion • if all the system’s facilities for storing and manipulating

its data are contained in this class.• if the class does not do anything other than manage its

data.

– Main advantage: When you need to make changes to the data, you find all the code in one place

44

Sequential cohesion

• Procedures, in which one procedure provides input to the next, are kept together – and everything else is kept out– You should achieve sequential cohesion, only once

you have already achieved the preceding types of cohesion.

45

Procedural cohesion

• Procedures that are used one after another are kept together– Even if one does not necessarily provide input to

the next. – Weaker than sequential cohesion.

46

Temporal Cohesion

• Operations that are performed during the same phase of the execution of the program are kept together, and everything else is kept out– For example, placing together the code used

during system start-up or initialization.– Weaker than procedural cohesion.

47

Utility cohesion

• When related utilities which cannot be logically placed in other cohesive units are kept together – A utility is a procedure or class that has wide

applicability to many different subsystems and is designed to be reusable.

– For example, the java.lang.Math class.

COUPLING

• Coupling occurs when there are interdependencies between one module and another. Figure illustrates the concept of a tightly coupled and loosely coupled system.

•Abstract examples of a tightly coupled system (left) and a loosely coupled system (right).• The boldness of the arrows indicates the strength of the coupling•In general, the more tightly coupled a set of modules is, the harder it is tounderstand and, hence, change the system.

• Two reasons for this are:• ■ When interdependencies exist, changes in one place will require

changes somewhere else.• Requiring changes to be made in more than one place is problematic

since it is time-consuming to find the different places that need changing, and it is likely that errors will be made.

• ■ A network of interdependencies makes it hard to see at a glance how some component works.

• Additionally, coupling implies that if you want to reuse one module, you will also have to import those with which it is coupled.

• This is because the coupled components need each other in order to work properly.

51

Content coupling:

• Occurs when one component surreptitiously modifies data that is internal to another component – To reduce content coupling you should therefore

encapsulate all instance variables• declare them private • and provide get and set methods

– A worse form of content coupling occurs when you directly modify an instance variable of an instance variable

52

Common coupling• Occurs whenever you use a global variable

– All the components using the global variable become coupled to each other

– A weaker form of common coupling is when a variable can be accessed by a subset of the system’s classes

• e.g. a Java package

– Can be acceptable for creating global variables that represent system-wide default values

Control coupling

• Occurs when one procedure calls another using a ‘flag’ or ‘command’ that explicitly controls what the second procedure does – To make a change you have to change both the calling

and called method– The use of polymorphic operations is normally the best

way to avoid control coupling – One way to reduce the control coupling could be to have

a look-up table• commands are then mapped to a method that should be

called when that command is issued

54

Example of control coupling

public routineX(String command){ if (command.equals("drawCircle") { drawCircle(); } else { drawRectangle(); }}

55

Stamp coupling:

• Occurs whenever one of your application classes is declared as the type of a method argument – Since one class now uses the other, changing the

system becomes harder• Reusing one class requires reusing the other

– Two ways to reduce stamp coupling,• using an interface as the argument type• passing simple variables

56

Example of stamp couplingpublic class Emailer{ public void sendEmail(Employee e, String text) {...} ...}

public class Emailer{ public void sendEmail(String name, String email, String text) {...} ...}

Using simple data types to avoid it:

57

Example of stamp coupling

public interface Addressee{ public abstract String getName(); public abstract String getEmail();} public class Employee implements Addressee {…} public class Emailer{ public void sendEmail(Addressee e, String text) {...} ...}

Using an interface to avoid it:

58

Data coupling• Occurs whenever the types of method

arguments are either primitive or else simple library classes – The more arguments a method has, the higher the

coupling • All methods that use the method must pass all the

arguments– You should reduce coupling by not giving methods

unnecessary arguments

59

Routine call coupling• Occurs when one routine (or method in an

object oriented system) calls another – The routines are coupled because they depend on

each other’s behaviour– Routine call coupling is always present in any

system.

– If you repetitively use a sequence of two or more methods to compute something

• then you can reduce routine call coupling by writing a single routine that encapsulates the sequence.

60

Type use coupling • Occurs when a module uses a data type

defined in another module – It occurs any time a class declares an instance

variable or a local variable as having another class for its type.

– The consequence of type use coupling is that if the type definition changes, then the users of the type may have to change

– Always declare the type of a variable to be the most general possible class or interface that contains the required operations

61

Inclusion or import coupling • Occurs when one component imports a package

– (as in Java)• or when one component includes another

– (as in C++). – The including or importing component is now exposed to

everything in the included or imported component.– If the included/imported component changes something

or adds something.• This may raises a conflict with something in the

includer, forcing the includer to change.– An item in an imported component might have the same

name as something you have already defined.

62

External coupling

• When a module has a dependency on such things as the operating system, shared libraries or the hardware – It is best to reduce the number of places in the

code where such dependencies exist.

ARCHITECTURAL STYLES

• The software that is built for computer-based systems exhibits one of many architectural styles.

• Each style describes a system category that encompasses – (1) a set of components (e.g., a database, computational modules)

that perform a function required by a system; – (2) a set of connectors that enable “communication, coordination and

cooperation” among components; – (3) constraints that define how components can be integrated to form

the system; and – (4) semantic models that enable a designer to understand the overall

properties of a system by analyzing the known properties of its constituent parts

Commonly used architectural patterns for software are as follows

Data-centered architectures

• A data store (e.g., a file or database) resides at the center of this architecture and is accessed frequently by other components that update, add, delete, or otherwise modify data within the store.

• Figure illustrates a typical data-centered style..

• Client software accesses a central repository. • In some cases the data repository is passive. That is, client software

accesses the data independent of any changes to the data or the actions of other client software.

• A variation on this approach transforms the repository into a “blackboard” that sends notifications to client software when data of interest to the client change.

• Data-centered architectures promote integrability. That is, existing components can be changed and new client components can be added to the architecture without concern about other clients (because the client components operate independently).

• In addition, data can be passed among clients using the blackboard mechanism (i.e., the blackboard component serves to coordinate the transfer of information between clients).

• Client components independently execute processes.

Data-flow architectures.

• This architecture is applied when input data are to be transformed through a series of computational or manipulative components into output data.

• A pipe and filter pattern (Figure a) has a set of components, called filters, connected by pipes that transmit data from one component to the next.

• Each filter works independently of those components upstream and downstream, is designed to expect data input of a certain form, and produces data output (to the next filter) of a specified form.

• However, the filter does not require knowledge of the working of its neighboring filters.

• If the data flow degenerates into a single line of transforms, it is termed batch sequential.

• This pattern (Figure b) accepts a batch of data and then applies a series of sequential components (filters) to transform it.

Call and return architectures

• This architectural style enables a software designer (system architect) to achieve a program structure that is relatively easy to modify and scale.

• A number of sub styles exist within this category:• (1)Main program/subprogram architectures

– This classic program structure decomposes function into a control hierarchy where a “main” program invokes a number of program components, which in turn may invoke still other components.

– Figure illustrates an architecture of this type.

• (2)Remote procedure call architectures. – The components of a main program/ subprogram architecture are

distributed across multiple computers on a network

Object-oriented architectures

• The components of a system encapsulate data and the operations that must be applied to manipulate the data.

• Communication and coordination between components is accomplished via message passing.

Layered architectures

• The basic structure of a layered architecture is illustrated in Figure. • A number of different layers are defined, each accomplishing operations

that progressively become closer to the machine instruction set.• At the outer layer, components service user interface operations.• At the inner layer, components perform operating system interfacing.• Intermediate layers provide utility services and application software

functions.

Identifying SubsystemSystem: A system is logical entity having a set of definable responsibilities or objectives and consisting of h/w, s/w or both. A system can have a specification which is then implemented by a collection of components

Subsystem: A subsystem is a system that is part of a larger system and which has a definite interface. Java uses packages to implement subsystems individual classes may also implement particular low level subsystem. Aggregation are special association that represent part whole relationships. The whole side of relationship is called as aggregate of assembly.

A subsystem is illustrated in UML as a special type of package with little upside down fork symbol in a small protruding base at the top left.A subsystem is drawn with three compartments :The operation shown towards the top left corner The specification elements (normally a use case diagram) shown towards the bottom left corner Realization elements (typically a class or interaction diagram on the right)

The mapping between realization elements and the other elements can be shown using dashed arrows with open triangles as arrowheads.