1. WORKFLOW OF SOFTWARE LIFECYCLE
MODULE 3
WORKFLOW OF SOFTWARE LIFECYCLE

2. 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.

3. 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

4. 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.

5. 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.

6. 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.

7. 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.

8. 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).

9. 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).

10. 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.

11. 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.

12. 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.

13. 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.

14. 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.

15. 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.

16. 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.

17. 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.

18. 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:

19. Problems of understanding
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.

20. 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.

21. For most systems, the work products include
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.

22. Requirement Elicitation (Gathering) Techniques (10 Marks)
Observation
Interviewing
Brainstorming
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.

23. 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.

24. 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.

25. 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.

26. 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.

27. 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.

28. 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?

29. 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.”

30. 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.

31. 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.

32. 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.

33. 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.

34. 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?

35. 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.

36. 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

37. System Design Concept- Cohesion & Coupling
Design Workflow
System Design Concept- Cohesion & Coupling

38. 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.

48. 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 to
understand and, hence, change the system.

49. 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

53. 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 coupling
public class er {
public void send (Employee e, String text)
{...}
... }
Using simple data types to avoid it:
public class er {
public void send (String name, String , String text)
{...}
... }

57. Example of stamp coupling
Using an interface to avoid it:
public interface Addressee {
public abstract String getName();
public abstract String get (); }
public class Employee implements Addressee {…}
public class er
public void send (Addressee e, String text)
{...}
...

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.

63. 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

64. 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..

65. 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.

66. 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.

67. 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.

68. 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.

69. (2)Remote procedure call architectures.
The components of a main program/ subprogram architecture are distributed across multiple computers on a network

70. 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.

71. 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.

72. Identifying Subsystem
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

73. 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.

74. 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)

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