SEFULL- 2mark 16 Marks With Answers

7/31/2019 SEFULL- 2mark 16 Marks With Answers

1/140

UNIT - I SOFTWARE PROCESS

1 . Define - Software process.

Software process is a sequence of steps with feedback

resulting in the production and evolution of software.

2. What are the three levels of the software process?

The three levels of software process are:

i. Universal level

ii. Worldly level

iii. Atomic level

3. Explain the three levels of software process.

The Universal level provides a software process model

suitable for any project. It can be decomposed to a worldly level

model.

The Worldly level model is project specific. In this level, the

needs, plans, methods and guides for a project are identified. It

specifies the sequences of tasks to be performed.

The Atomic level model comprises of detailed sequence

steps. This level is where the software process becomes task

specific.

4. Explain feedback system.

Product development is characterized by an overlapping of

activities needed to specify, design and list conceptual constructs

of software being built. The collection of activities making up a

software process forms a feedback system.

5. What are the four principle forms of feedback? Explain

them.

The four principle forms of feedback are:

i. Software entity measurements : Numbers derived from resultsproduced by effectors processes.

ii. Corrective: Feedback due to software errors, faults and failures.

iii. Change: Modify software to eliminate defects.

iv. Improvement: Enhance software.

6. Differentiate between software defect and software error.

Software defect

A software defect is a product anomaly. Eg : Omission of a

required feature or imperfection in the product.

Software error

A software error is an observed difference between a computed

value and a required value or condition. Eg : error due to misinter-

pretation of a specific software requirement


2/140

7. Differentiate between software fault and software failure.

Software faultSoftware contains a fault whenever it has an incorrect step,

process or data definition

Software failure

A software failure occurs when the software is unable to perform

its required function

8. Define - Effector.

An effector is a process that performs some task, verifies its work

and exits whenever its exit condition has been satisfied.

9. Define - Decider.

Decider is a process that determines if the entry condition for a

task has been satisfied and chooses an appropriate effector to carry

out a task.

10. What is an ETVXM architecture

The combination of a decider, effector and a measure

defines an Entry, Task, Verify, Exit, Measure (ETVXM) process

architecture with feedback. Feedback to a decider processprovides the basis for iterative refinement of project requirements

and design.

11. Explain the correspondencebetween feedback and

ETVXM process.

The cluster of effector boxes represents various concurrent

software development sub processes in the software process. Each

effector process consists of a principal activity that produces a

software entity that must be measured.

Feedback must be compared with the project blueprint and

software engineering guide to check for discrepancies and

16. What are theprocesses involved during the

development of a software?

Three processes are involved during the development of asoftware. They are:

i. Requirements: Decide what a system must do, its activities,

its risks and testing plan.

ii. Design: Determine how a system computes, its specific

functions and structure.

iii. Implementation: Produce source code, documentation and

tests, validate and verify.

17. Define - Software Process Model.

A Software Process Model prescribes a frame work for

principal project activities, inputs, outputs and constraints.

18. Explain Waterfall Model.

Waterfall Model uses a sequence of activities in a Software


3/140

Life Cycle that began with concept exploration and concluded

with maintenance and eventual replacement. The sequence of

activities are:

i. Concept exploration

ii. Requirementsiii. Design

iv. Implementation

v. Test

vi. Installation and check out

vii. Operation and maintenance

viii. Replacement

19. What are the problems encountered in the Classic Life

Cycle Model?

The frequently encountered problems in linear sequential

model are:

i. Real projects rarely follow the sequential flow.

ii. It is often difficult for the customer to state all requirements

explicitly.

iii. A client must wait until the installation and check out phase to

see how a system works.

20. What is a prototype?

A prototype is an executable model that accurately reflects a

subset of the properties of a system being developed.

21. Explain Incremental Model.

The Incremental Model combines elements of the linear

sequential model with the iterative philosophy of prototyping. The

incremental model applies linear sequences in a staggered fashion

as calendar time progresses. Each linear sequence produces a

deliverable "increment" of the software.

22. Define the terms (i) Increment (ii) Core product.

(i) The incremental model delivers software in small but

usable pieces called "increments". Each increment builds on those

that have already been delivered.

(ii) When an incremental model is used, the first increment

is called a "Core product". In this, the basic requirements are

addressed but many supplementary features remain undelivered.

23. Which model is used when staffing is unavailable and

why?

Incremental model is used when staffing is unavailable for a

complete implementation by the business deadline that has been

established _ the project. Early increments can be implemented

with fewer people. If the core product is well received, then

additional staff can be added to implement the next increment.

24. Briefly describe Spiral Model.

Spiral Model is an evolutionary software process model that

couples the iterative nature of prototyping with the controlled

systematic aspects of linear sequential model. With this model, the


4/140

software is developed in a series of incremental releases. In early

iterations, the release is a prototype and in the later iterations, a

complete version of the engineered system is produced.

25. What is meant by task regions? List the six task regions.

Spiral model is divided into a number of framework activities

called task regions. The six task regions are as follows:

i. Customer communication

ii. Planning

iii. Risk Analysis

iv. Engineering

v. Construction and release

vi. Customer evaluation.

26. What is a "task set" ?

Spiral model comprises of a number of task regions. Each of

the regions is populated by a set of work tasks called "task set"

that are adapted to the characteristics of the project to be

undertaken.

27. Explain WINWIN spiral model.

WINWIN spiral model defines a set of negotiation activities

at the beginning of each pass around the spiral. The following

activities are defined:

1. Identification of the system or subsystem's key 'Stakeholders'.

ii. Determination of the stakeholder's win conditions.

iii. Negotiation of stakeholders win conditions to reconcile theminto a set of win-win conditions.

On completion of these steps successfully, it results in aWIN- WIN result that becomes a key criterion for proceeding tosoftware and system definition.

28. What is an anchor point? Explain the three anchor

points of WINWIN spiral model.

The milestones that establish the completion of one cyclearound the spiral and provide decision milestones before the

project proceedings is called an anchor point.

The three anchor points are:

i. Life Cycle Objective (LCO) is a set of objectives for each majorsoftware engineering activity.

ii. Life Cycle Architecture (LCA) - objectives that must be met asthe system and software architecture is defined.

iii. Initial Operationa1 Capability (lOC) is a set of objectives

associated with the preparation of the software for installation /

distribution.

29.What are the disadvantages of Evolutionary

Model?

The disadvantages of Evolutionary Model are:

i. It can be costly if the current release is made with an

assumption that it will be succeeded by an improved version of the

software later. .


5/140

ii. They are used on large software systems.

30. Explain the prototyping paradigm.

Customer and developer meet and define the objectives for

the software. As a result, a 'quick design' occurs that leads to theconstruction of a prototype, which is evaluated by the user.

Iteration occurs as the prototype is tuned to satisfy the needs of thecustomer.

31. What are the disadvantages of prototyping model?

The disadvantages of prototyping model are:

i. Long term maintainability is difficult, as the working

prototype may need to undergo few fixes in the future.

ii. The developer often makes implementation compromises to

get a working prototype quickly.

32. Briefly describe Object - Oriented Model.

Object - Oriented Model describes software development in

terms of the identification of objects used to construct object

networks. It prescribes software development in terms of a

synergy between abstraction, modularity, encapsulation,

hierarchy, typing, concurrency and persistence. The development

phase of the object-oriented model culminates in implementation

coded in an object-oriented language such as C++ or Java.

33. Explain the terms: Abstraction,Modularity, Encapsulation,

Hierarchy, Typing, Concurrency and

Persistence.

Abstraction hides details and provides simplified descriptions of a

system.

Modularity is partitioning a software system into modules that canbe compiled separately and identifying connections with other

modules.

Encapsulation hides the implementation details of an object.

Hierarchy refers to abstractions ordered in terms of super classes

and subclasses.

Typing identifies structural and behavioral properties that a

collection of entities share.

Concurrency permits more than one thread of control to be active

at the same time.

Persistence means that the state and class of an object are

preserved across time and space.

34. What are the advantages of object-oriented

approach?

The advantages are:

i. It simplifies the software development as it hides complexity.

ii. The development of classes supports multiple instances of

objects as well as encapsulation that leads to reuse.


6/140

35.What is an embedded computer system? Give

four examples.

An embedded computer system is an electromechanicalsystem governed by one or more computers. The computer in an

embedded system performs some of the requirements of that

system, making it possible for the system to carry out its

functions.Eg.

i. Rocket guidance systems.

ii. Avionics systems for civilian and military aircraft

iii. Recent models of automobilesiv. Satellites.

36. .Briefly explain Synchronize and Stabilize

Model.

Synchronize and Stabilize Model is used by Microsoft to

develop software. It has three phases, namely:

i. Planning: Define product vision and specification; schedule the

tasks.

ii. Design: Feature development, 3 or 4 sequential subprojects

with milestones.

iii. Stabilization: Comprehensive internal and external testing,

final product stabilization and release.

37.What are the drawbacks of synchronize and

stabilize model.

The drawbacks of synchronize and stabilize model are:

i. Reliance on testing and debugging to determine when an

increment is stable. Consideration of the proof of the functional

correctness of an increment has not been reported.

ii. Partition of design phase into three subprojects, each with one-

third of the features of a product. For a large system, smaller

partitions will be necessary.

38. What is "System Engineering" ?

Software engineering occurs as a consequence of a process

called "System Engineering". It focuses on a variety of elements,

analyzing, designing and organizing those elements into a system

that can be a product, a service or a technology for the

transformation of information or control.

39.What is the work product during system

engineering?

An effective representation of the system must be produced

as a. consequence of system engineering called the work product.

It can be a prototype, a specification or even a symbolic model but

it must communicate the operational, functional and behavioral

characteristics of the system to be built and provide insight intothe system architecture.

40. Define - Computer -basedsystem.

According to webster, a computer-based system is defined as "A

set or arrangement of elements that are organized to accomplish

some predefined goal by processing information".


7/140

41. What are the system elements involved in accomplishing

the goal of a computer - based

system?

To accomplish the goal, the computer-based system uses thefollowing system elements, namely:

i. Software: Computer programs, data structures and related

documentation.

ii. Hardware: Electronic devices with computing capability,

electromechanical devices and interconnectivity devices.

iii. People: Users and operators of hardware and software.

iv. Database: A large, organize_ collection of related information

accessed via software.

v. Documentation : Descriptive information tha1 portrays the

use and/or the operation of the system.

vi. Procedures: Steps that define the use of each system

elements or procedural context in which the system resides.

42. Explain the System Engineering Hierarchy.

The systell1 engineering process usually begins with a

"world view". The entire business or product domain is examined

to ensure proper business or technology context that can be

established. The world view is refined to focus more fully on

specific domain of interest. The need for targeted system elements

is analyzed in the specific domain.

Finally analysis, design and construction of a targeted

system element is initiated.

43. List the restraining factors in constructing a system model

The restraining factors in constructing a system model are:

i. Assumptions

ii. Simplifications

iii. Limitations

iv. Constraints

v. Preferences

44. What is the goal of business process engineering?

The goal of business process engineering is to define architecturesthat will enable a business to use information effectively.

45. Explain the three architectures developed during business

process engineering.

The three architectures developed during business process

engineering are:

i. Data architecture

ii. Application architecture

iii. Technology Infrastructure

Data architecture provides a framework for the information needs

of a business or business function.

Application architecture encompasses those elements of a system

that transform objects within the data architecture for some

business purpose.


8/140

The technology infrastructure provides the foundation for the data

and application architectures.

46. What is information strategy planning?

Information strategy planning defines the data objects that are

visible at the enterprise level, their relationships and how they

flow between the business domains.

47. Briefly describe business area analysis.

Business area analysis is concerned with identifying in detail, data

of selected business .areas identified during ISP and ascertaining

their interactions. It is only concerned with specifying what is

required in a business area.

48. What is meant by product engineering?

Product engineering is a system engineering approach that begins

with system analysis. The system engineer identifies the

customer's needs, determine economic and technical feasibility

and allocates function and performance to software, hardware,

people and databases.

49. How is the world view and the domain view achieved in

product engineering?

World view is achieved through requirements engineering. The

overall requirements of the product are elicited from the customer.

Domain view is achieved through system component engineering.

System component engineering is a set of concurrent activities

that address each of the system components separately. The

system components are software engineering, hardware

engineering, human engineering and database engineering.

Part - B

Software

Process

1. Explain Waterfall Model.

The first published model of the softwaredevelopment process was derived from otherengineering process. This is illustrated from followingfigure. Because of the cascade from one phase toanother, this model is known as "Water fall model" or"Software life cycle model". The principle stage of themodel map on to fundamental development activities.

(i)Requirement analysis and definition : The

systems services constraints and goals areestablished by consultation with systemusers. They are then defined in detail andserve as system specification.

(ii)System and Software Design : The systemdesign process partition the requirementsto either hardware or software systems. Itestablishes an overall system architecture.Software design involves identifying anddescribing the fundamental software system

abstraction and their relationship.(iii)Implementation and unit testing : During thisstage the software design is realized as a set


9/140

of programs or program unit. Unit testinginvolves verifying that each unit meets its

specification


10/140

2. Explain the Concept of software process.

RequirementDefinitions

System &Soft-ware design

Implemen-

tation

Integration

Operation &Maintenance

(iv)Integration and system testing : Theindividual program units or programs areintegrated and tested as a complete systemto ensure that the software requirementhave been met. After testing the softwaresystem is delivered to the customer.

(v)Operation and maintenance : The system is

installed and put into practical use.Maintenance involves correcting errors whichwere not discovered in earlier stages of lifecycle.


11/140

The following are the basic principles to develop asoftware process.

(i)Structured set of activities required e.g.Specification, Design, Validation, Evolution

(ii) Activities vary depending on theorganisation and the type of system beingdeveloped

(iii)It Must be explicitly modelled if itis to be managed

In order to analysis software process wemust clearly mention the ProcessCharacteristics

(i)Understandability(ii) Visibility(iii) Supportability(iv) Acceptability(v) Reliability

(vi) Maintainability(vii) Rapidity

Generic building is a type of software bulidingthat build any product some points to remember are:

(i)Specification - set out requirementsand constraints

(ii) Design - Produce a paper model ofthe system


12/140

(iii) Manufacture - build the system

(iv) Test - check the system meets

the required specifications(v) Install - deliver system to customer

and ensure it is operational

(vi) Maintain - repair faults in thesystem as they are discovered

(vii) Normally, specifications areincomplete / anomalous

(viii) Very blurred distinctionbetween specification, design andmanufacture

(ix)No physical realisation of the systemfor testing

(x) Software does not wear out -maintenance does not meancomponent replacement

main purpose of software process model is to giverisk-reducing structure and growing

recognition that in many cases software should bedeveloped in an evolutionary fashion

e.g. Microsoft Visual C++ is shipped every 4months

2.Explain about prototyping Model.3.

In Waterfall model Separate and distinct phasesif specification and development are provided.Where as in Prototyping Models

and


13/140

Evolutionary Models Specification and developmentare interleaved

Prototyping is used in 2 types they are

(i)Evolutionary prototyping : Objective is to workwith

customers and to evolve a final system froman initial outline specification. Should startwith well-understoodrequirements

(ii) Throw-away prototyping : Objective is tounderstand the system requirements.Starts with poorly understoodrequirements

Requirements are difficult to capture accurately.Prototype is a working model of part or all of the final

system and use of high-levellanguages to create working programs quickly. Nowa days modern 4GLs are very suitable. Prototype maybe inefficient/ not as robust as finalsystem/ less functionality

Problems with Prototyping

(i)Documentation may get neglected

(ii)Effort in building a prototype may be wasted

(iii)Difficult to plan and manage

Advantages

(i)Faster than the waterfall model

(ii) High level of user involvement from start


14/140

(iii)Technical or other problems discoveredearly - risk reduced

Strategies

(i)Evolutionary

Prototyping

(ii)Incremental (Staged)

Delivery (iii)Design-to-

Schedule

(iv)Evolutionary

Delivery

Problems with Evolutionary Prototyping

(i)Difficult to plan as amount of effort isuncertain(ii) Documentation may be neglected

(iii)Could degenerate into Build and Fix withpoorly structured code(iv)Languages which are good for prototyping

not always best for final productAdvantages

(i)Effort of prototype is not wasted(ii)Faster than the waterfall model(iii)High level of user involvement from start(iv)Technical or other problems discoveredearly - risk reduced

4. Explain Incremental and Requirement

Analysis in detail. Mechanism

(i)requirements gathered in initial stages


15/140

(ii)overall architectural design is determined

(iii)requirements met in successive stages of theproject

(iv)users get part of the functionality deliveredat an early stage (As in evolutionaryprototyping)

Problems

(i)Needs careful planning - stages have

interdependencies (ii)If not planned well -

extra effort in interfacing stages

(iii)Users may tire of constant changes

(iv)funding may be difficult to obtain for asuccession of changes

Requirement Analysis

The process of establishing the servicesthat the customer requires from a system and theconstraints under which it operates and is developed

What is a requirement?

(i)may range from a high-level abstractstatement of a service or of a systemconstraint to a detailed mathematicalfunctional specification

(ii)Requirements may serve a dual function(iii)May be the basis for a bid for a contract -

therefore must be open to interpretation(iv) May be the basis for the contract itself -

therefore must be defined in detail


16/140

(v) Both these statements may be calledrequirements

Requirements definition

A statement in natural language plusdiagrams of the services the system providesand its operational constraints. Written forcustomers

Requirements specificationA structured document setting out detaileddescriptions of the system services. Writtenas a contract between client and

contractor. For customers +developers

Software specification

A detailed software description which can serve as abasis for a

design or implementation. Written for developers

5. What are the problems in Requirement

analysis and write short notes on Nonfunctional and requirment verification?

The following are the some of the problems of

requirement

analysis. (i)Hard to anticipate the effects that

the new system will have on

theorganisation

(ii)Different users have different requirements

and priorities. (iii)System end-users and

organisations who pay for the systemhave differentrequirements

(iv)Prototyping often required to clarifyrequirements


17/140

(v)Natural language problems

Non Functional Requirements

(i)Define system properties and constraintse.g. reliability, response time and storagerequirements. Constraints are I/O devicecapability, system representations, etc.

(ii)Process requirements may also bespecified mandating a particular CASE

system, programminglanguage or development

method

(iii)Non-functional requirements may bemore critical than functional requirements.If these are not met, the system is useless

Requirement Verifiability

(i)Requirements should be written so that theycan be objectively verified

(ii) The problem with this requirement is itsuse of vague terms such as errors shall beminimised

(iii)The system should be easy to use byexperienced controllers and should beorganised in such a way that user errors areminimised.

(iv)The error rate should be quantified

(v) Experienced controllers should be able touse all the system functions after a total oftwo hours training. After this training, theaverage number of errors made byexperienced users


18/140

should not exceed two per day.

Advantages

(i)Effort of prototype is not wasted(ii)Faster than the waterfall model

(iii)High level of user involvement from start

(iv)Technical or other problems discovered early- risk reduced

6. Explain the Evolution of Software Designapproach

Evolution of Software Design Approaches are :

(i)procedural aspects of design definitionled to structured programming

(ii)Forms a top-down approach to design

(iii)SA/SD methods for translation of data flow ordata structure into a design definition -functional design methods

(iv) Abstract Data Types have led to Object-Oriented approaches to design definition -higher level abstractions

(v) Formal design specificationtechniques have led to

transformational approaches todesign

(vi)Increasing formalization andautomation of implementation


19/140

Common Characteristics of Design Approaches

(i)Mechanism for the translation of theapplication domain representation intothe design representation

(ii) A notation for representing functionalcomponents and their interfaces

(iii)Heuristics (rules-of-thumb) for refinementand partitioning of design

(iv)Guidelines for qualityassessment

An Application of OOD Method

A numerical control (NC) for machine tools is to bedeveloped. The NC is programmed with machineinstructions and produces control commands for themachine tools servosystem. In addition the NCcontains a CRT display and keyboard for operator

interaction.

Develop a numerical control for a machine tool thatreads NC blocks and operator commands andproduces machine servosystem controlcommands and a CRT display.

7. What are the procedures and notion tobe used for Object, Operation Design andRefinement

(i)Identify all noun and verb phrases

(ii)Build object table using nouns


20/140

(iii)Separate out Problem and Solutionspace objects

(iv) Build object-operation table usingverbs

(v) Refine object-operation table

(vi)Add attributes to objects

(vii)Construct various views of designusing class diagrams (logical),

interaction and/orstate diagrams

(process),implementation/deploymentdiagrams (physical) and component/development diagrams (development).

(viii)Prepare to testtheimplemented designby developing scenarios of use

- I.e. there should be at least onescenario related to each function orfeature required by the user.

(ix) Review and repeat if necessary.

Comparison of FunctionalDesign and OOD

1.There is no best design strategy.

2.Designers should employ whicheverapproach seems most appropriate for aparticular system.

3.From an initial natural language view, it is easierto identify the set of objects that comprise thesystem than the set of functions.


21/140

4.Once functional requirements have beenidentified linking these to a functionalview of the system aids traceability.

(v)Often a heterogeneous approach e.g.combining DFDs with OO

diagrams is useful.

Somerville says: The functional approach todesign using data-flow

diagrams is probably the most intuitiveway to describe the overall design. However,the focus on function means thatthe reader of the design finds it more difficultto understand entities which are manipulated bythe system.

8.Differentiate between Prototype andSpiral Model

Prototype Model

In most projects, the first system is barelyusable...When a new system concept of newtechnology is used, one has to build a system tothrow away, for even the best planning is not soomniscient as to get it right the first time. The

management question, therefore, is not whether tobuild a pilot system and throw it away. You will dothat. The only question is whether to plan in advanceto build a throwaway, or to promise to deliver thethrowaway to customers.

Usually, this model replaces part of thewaterfall model--the requirements anddesign part. The main problems are :

(i)The user thinks that the prototype is a finishedproduct.(ii) Quick and dirty design and coding in the

prototype may remain in the product.Not all problems are more easily or better solved byprototyping. Works


22/140

better on on the edge products.The Spiral Model

(i)Not as bad as it looks.

(ii)Its a sort of curled-up incrementalwaterfall with prototyping thrown in.(iii)Defined as passing through 4-6 task regions,often(iv)Customer communication(v)Planning(vi)Risk analysis(vii)Engineering(viii)Construction andrelease (ix)Customerevaluation

Development travels around the spiral, with definedtasks in each task region. First pass around thespiral is often development of a specification, thenext is a prototype, and the next a productionproduct. Maintenance is yet another.

As the Model concerns

(i)Risk analysis is an important part of theprocess(ii) Has the good points of prototyping. In fact,

it includes portions of other models.(iii) Maintenance is part of the process in thesame way that other

parts are--less apt to beforgotten. (iv)Seems to betheoretical only.(v)Complexity(vi)Risk analysis is a hard thing to come by inmost projects.(vii) Managers are hard to sell on it, as it is not

fast (and cant be made to appear fast.)


23/140

9. Explain Software Validation.Software validation is intended to show that asystem is confirm to its specification and that thesystems meets the expectations of a customerbuying the systems. It involves checking processsuch as inspections and reviews at the each stage ofthe process.

The majority of validation costs are incurredafter the operational systems are tested.

Except for small programs systems should not betested as a single unit. Large systems are built outof sub systems which are built out of modules whichare composed out of procedures and functions.

The testing process should therefore proceed in astage where testing is carried out incrementallywith conjunction with system implementation,.

The Stages in the testing process are :

(i)Unit Testing : Individual component aretested to ensure that they operate correctly.

(ii)Module Testing : A Module is a collectionof dependant

component such as an object class, an

abstract data type. A Module encapsulatesrelated components, so can be testedwithout other system module.

(iii)Sub System checking : This phase involvestesting collections of module which havebeen integrated into sub systems. The mostcommon problems which arise in largesoftware systems are interfaces mismatch.

(iv)System Testing : The subsystems areintegrated to make up the systems. Thisprocess is concerned with finding errorsthat result from unanticipated interactionbetween sub systems and


24/140

sub systems interfaceproblems.

(v)Acceptance testing ; This is the final stage in

the testing process before the system isaccepted for operational use. The system istested with data supplied by the systemscustomers rather than simulated data.

Unit testing and modular testing are usually theresponsibility of the programmers. They make uptheir own data and incrementally tested test the codeas it is developed.

Later stage of testing involves integrating workfrom a number of programmers and must beplanned in advance. An independent team of testershould work from pre formulated test plans whichare developed from the system specification anddesign.

These are the main key points ofvalidation Process.

10.Explain the Computer based System inSoftware Approach.

A set or arrangement of elements that are organizedto accomplish some method, procedure or controlby processing information. Elements include:hardware software people users and operatorsdatabase documentation procedures the steps thatdefine the specific uses of each system element or

the procedural context in which the system resides.Systems transform information. Systems can contain,

as elements, other systems. Computer SystemEngineering or Systems Analysis system functionsare discovered, analyzed and allocated toindividual system elements. Customer-defined goalsand constraints are used to derive a representationof function, performance, interfaces, designconstraints and information structures for eachsystem element. tasks include:


25/140

identify desired functions ``bound' or identify thescope of various elements/functions allocatefunctions to system elements alternatives areproposed and evaluated selection criteria include:project considerations - scheduling, cost, riskbusiness considerations marketing, profit,risk technical analysis - function, performancemanufacturing evaluation - availability, qualityassurance human issues - workers,customers environmental interfaces -

system'sexternal environmentlegal considerations - liability,

infringement Systems Analysis

Systems Analysis is conducted with the followingobjectives: identify the customer's needs evaluatethe system concept for feasibility performeconomic and technical analysis allocate functions tothe various system elements establish cost andschedule constraints create a system definitionthat forms the foundation for all subsequentengineering work . Pervasive SystemRequirements

There are many other categories of requirementsthat also deserve attention pervasive systemrequirements include:

(i)accessibility(ii)reusability(iii)adaptabili

ty(iv)robustness(v)availability(vi)safety(vii)compatibility(viii)security(ix)correctness

(x)testability(xi)efficiency(xii)usability(xiii)faulttolerance(xiv)integrity(xv)maintainability performanceportability protection & (xvi)reliability


26/140

UNIT-II SOFTWARE REQUIREMENTS

1. What are functional requirements?

Functional requirements are statements of the services that

must provide descriptions of how computations must be carried

out. Domain requirements are functional requirements that are

derived from characteristics of the application domain.

2. What are non-functional requirements?

Non-functional requirements are product requirements thatconstrain the system being developed, process requirements which

apply to the development process and external requirements. They

often relate to the emergent properties of the system and so applyto the system as a whole.

3. Classify the different types of non-functional requirements.

The different types of non-functional requirements can be

classified as :

i. Product requirements

ii. Organisational requirements

iii. External requirements

4. List the metrics for specifying non functional

requirements.

The possible metrics that specify the non-functional requirements

are: .

i. Speed

ii. Sizeiii. Ease of Use

iv. Reliability

v. Robustness

vi. Portability

5. What is the need for user requirements? Mention the

problems that arise when requirements are written in natural

language.

User requirements are useful for people involved in using andprocuring the system., The problems that arise when requirements

are written in natural language are:

i. Back of clarity

ii. Requirement confusion

iii. Requirements amalgamation

6. What guidelines do you think will minimize

misunderstandings when writing user requirements?

To minimize misunderstandings when writing user requirements,

th\e following guidelines can be used:

i. Invent a standard format and ensure that all requirement

definitions adhere to that format.

ii. Use language consistency.


27/140

iii. Use text highlighting

iv. Avoid, as far as- possible, the use of computer Jargon.

7. Write short notes on system requirements.

System requirements are intended to communicate, in aprecise way, the functions which the system must provide. .To

reduce ambiguity, they may be written in a structured language of

some kind. This can be a structured form of a natural language, a

language based on a high-level programming language or a special

language for-requirements specification.

8. List the notations used for requirements specification.

The notations used for requirements specification are:

i. Structured natural language.

ii. Design description languages.

iii. Graphical notations.

iv. Mathematical specifications.

9. What information must be included while specifying

functional requirements?

The information to be included while specifying functional

requirements are given below:

i. A description of the function or entity being specified. ii.

A description of its inputs and where these come from.iii. A description of its outputs and where these g? to. iv. An

indication of why other entities are used.

v. If a functional approach is used, a pre-condition setting out

what must be true before the function is called and a post-

condition specifying what is true after the function is called.

vi. A description of the side-effects of the operation.(if any).

10. What is a software requirements document (SRD) ?

A software requirements document (also called as software

requirements specification or SRS) is the official statement of

what is required of the system Developers. It should include both

the user requirements for a system and a detailed specification of

the system requirements.

_11. What is meant by Requirements Engineering?

Requirements Engineering is a process that involves all theactivities required to create and maintain a system requirements

document. The process activities include a feasibility study,

elicitation and analysis of requirements, the specification of

requirements and their documentation and finally the validation of

these requirements.


28/140

ii. Problems of understanding: Customers/users have a poor

understanding of the capabilities and limitations of their computing environment.

12. Write notes on Feasibility studies.

A Feasibility study is a short, focused study that aims toanswer a number of questions, namely:

i. Does the system contribute to the overall objectives of theorganization?

ii. Can the system be implemented using current technology andwithin given cost and scheduled

constraints?

iii. Can the system be integrated with other systems that are

already in place?

The input to the feasibility study is an outline description of

the system .and it will be used within an organization. The results

should be a report that recommends whether or not it is worth

carrying on with the requirements engineering and system

development process.

13. Why is it so difficult to gain a clear understanding of what

the customer wants?

It is difficult to gain a clear understanding of what the customerwants, due to the following reasons:

i. Problems of scope: The boundary of the system is well-defined.

iii. Problems of volatility: The requirements change over time.

14. What is the use of requirements validation?

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.

15. List the type of checks that needs to be carried out on the

requirements in the requirements document during the

validation process.

The checks that should be carried out during the validation

process-are:

i. Validity checks

ii. Consistency checks

iii. Completeness checks

iv. Realism checks

v. Verifiability


29/140

requirements engineering processes.

19. Classify requirements from an evolution perspective.

16. List four requirements validation techniques.

The four requirements validation techniques are:

i. Requirement reviews

ii. Prototyping

iii. Test-case generation

iv. Automated consistency analysis

17. Why do new requirements emerge?

New requirements emerge for the following reasons:

i. Large systems usually have a diverse user community. Different

users have different requirements and priorities. These may be

conflicting or contradictory.

ii. System customers impose requirements because of organisational

and budgetary constraints. These may conflict with end-user

requirements.

iii. The business and technical environment of the system changes

and these must be reflected in the system ,itself.

18. What is meant by requirements management ?

Requirements management is the process of understanding

and controlling changes to system requirements. The process of

requirements management is carried out in conjunction with other

From an evolution perspective, requirements fall into two

classes:

i. Enduring requirements: These are relatively stable

requirements that derive from the core activity of the

organization and relate to the domain of the system.

ii. Volatile requirements: These are requirements that are

likely to change during the system development or after

the system has been put into operation.

20. Classify Volatile requirements.

Volatile requirements fall into four categories:

i. Mutable requirements

ii. Emergent requirements

iii. Consequential requirements

iv. Compatibility requirements

21. Write short notes on planning.

Planning is an essential stage in requirements management

process that establishes the level of requirements managementdetail that is required. The following must be decided during the

requirements management stage:

i. Requirements identification

ii. Change management process

iii. Traceability policies

iv. CASE tool support


30/140

22. Define - Traceability. List the types of traceability

information.

Traceability is an overall property of requirements specification

that reflects the ease of finding related requirements. The three

types of traceability informations are:

i. Source traceability information

ii. Requirements traceability information

iii. Design traceability information

23. With a neat diagram, explain change management process.

Change management process

The process starts with an identified requirements problem,

sometimes with a specific change proposal. The effect of the

proposed change is assessed using traceability information and

general knowledge of system requirements. Once analysis is

completed, a decision is made whether or not to proceed with the

requirements -change. The requirements document and, where

necessary, the system design and implementation are modified.

24. What is a prototype? List any four benefits of using

prototyping in software process.

A prototype is an initial version of a. software system,

which is used to demonstrate concepts, tryout design options and

generally, to find out more about the problem and its possible

solutions.The benefits of using prototyping in the software process

are:

i. Improved system usability.ii. A closer match of the system to the User needs iii. Improved

maintainability iv. Reduced development effort

26. Differentiate between evolutionary and throw-away

prototyping.

Evolutionary prototyping

i. The objective is, to deliver a working system to end users.

ii. They should have a robust structure so that they aremaintainable for many years

iii. They should be reliable and efficient and they should conform

to relevant organizational standards.

Throw-away prototyping

i. The objective is to validate or derive the system requirements.ii. They have a short lifetime.

iii. Poor performance and reliability may be acceptable.

27. Mention any two fundamental characteristics of rapid

software development?

The two fundamental characteristics of rapid software

development are:


31/140

i. The system is developed as a series of increments" End-users and

other system stakeholders are involved in evaluating and

designing each increment. They may propose 'changes to the

software' and new requirements should be .implemented in later

version of the system.

ii. Techniques for rapid system development are used. These include

CASE tools and fourth-generation languages.

28. What are rapid prototyping techniques? Mention the rapid

prototyping techniques used for developing industrial -

strength prototypes.

Rapid prototyping techniques are development techniques

which emphasize speed of delivery rather than systemcharacteristics such as performance, maintainability or reliability.

There are three rapid development techniques for developing

industrial-strength prototypes 'namely: '

i. Dynamic high level language development ii. Database

programming iii. Component and application assembly

PART - BSOFTWAREREQUIREMENT

1. Explain Rapid SoftwarePrototyping.

software rapid prototype is a dynamic visualmodel providing a communication tool for customer

and developer that is far more effective than eithernarrative prose or static visual models forportraying

functionality.

It has been described as: Functional after a minimum

amount of effort A means for providing users of aproposed application with a physical representationof key parts of the system before systemimplementation

Flexible: modifications require minimaleffort Not necessarily representative

of a complete system

Software prototyping is an information systemdevelopment methodology based on building andusing a model of a system fordesigning, implementing, testing, and installing thesystem.

A software mock-up is a system developmentapproach based on building and using a model of asystem for discovering the requirements of thesystem.

Critical objectives of software development are mosteffectively achieved through rapid prototyping isgiven by as follows.

Rapid prototyping is basically an analysis technique.discovery of the true and complete set of functionalrequirements for a proposed system In classic alsoftware development, the client usually cannot

view a physicalrepresentation of the final system until thetesting phase. this is critical in projects with verylong development times results in a very lowprobability of delivering an acceptable software


32/140

system

There are six different tool-dependent approaches incurrent use: AI - LISP or PROLOG on a dedicatedmachine Mainframe - based on DBMS technology NIH(Not Invented Here) - proprietary rapid prototyping

systems ADA - based on reusable code packages andprogram libraries, i.e. features of the language BareHands - based on perceived absence of arequirement RDMS - based on relational DBMStechnolgy and


33/140

interfacetools

About 50 percent of the development effort is user

contributions. The users will always be present.Throaway Prototypesa product designed to be usedonly to help the customer identify requirements for anew system the product cannot be implemented oreven evolved into a deliverable system - only thederived requirements will be maintained often aresult of tools that are unsuitable for use inproduction systems.

2. Explain Requirement

Elicitation.

In its simplest possible form the requirementselicitation process might be considered as aconversation between the client andthe software engineer that results in anunderstanding by the software engineer of whatthe customer wants. Life is seldom that simplehowever and experience has shown that althoughEliciting requirement is easiest when there is a good

understanding of the application domain. It isessential that the requirements engineerunderstands the application domain but how do youknow that you understand it? You might think thatwhen the user says a crank hard and support theFox-1 unless you know what they mean but how canyou be sure?

One way is to gain experience in the applicationdomain (more about this

in the lecture) but there are problems with that.The knowledge clients have is built up over yearsdo you have years to

spend on requirement elicitation? Also the clientsknowledge may be spread amongst many peopleso you would inevitably need to gain experiences inmany different aspects of the clients business. Soexperience of the users domain, whilst clearlyvaluable and useful, cannot be the only answer.

There is simply not the time for the requirementsengineer to become expert in the application domain.

Though the return for investment on somefamiliarization is usually large.


34/140

The answer is to develop an explicit conceptual modelof the domain and to present that back to the clientfor verification.

Requirements Elicitation might be described aseliciting a specification of what is required by

allowing experts in the problem domain to describethe goals to be reached during the problemresolution. This being so, we may be limited to havinga vague desire at the beginning of the process, suchas "We want a new aircraft carrier", and at the endof the process having a detailed description of thegoals and some clear idea of the steps necessary toreach the goals.

There are several things wrong with this description.

Where does the logical model reside, in people'sheads? Is there an expert with sufficient breadth anddepth of domain knowledge to ensure the goal andall its subgoals are consistent and achievable? Ifthere is not, are we merely leaving to the designstage the process of systematising the subgoals. It isvery likely that many goals will be inconsistent,even deliberately contradictory. Can we say

the Requirements Elicitation stage is completewhile this is so? We certainly can if our methods forsupporting the elicitation have no means ofestablishing the consistency of the goals. How precisedo we need to be in specifying our goals. Is thereanything left to do in the design stage, or have we

gazumped it by not having a method of descriptionthat permits variability in the requirements.

3. Explain aboutRequirement Validation.

Requirement validation ensures capturedrequirements reflect the functionality desired bythe customer and other stakeholders. Althoughrequirement validation is not the focus of

requirement testability analysis, it is supported.Requirement validation involves an engineer,user or customer judging the validity (i.e.correctness) of each requirement. Models providea means for stakeholders to precisely understandthe requirements and assist in recognizingomissions. Test automatically


35/140

derived from the model support requirementvalidation through manual inspection or executionwithin simulation or host environments.

Requirement validation is the final stage of

requirements engineering.

Purpose of RequirementValidation

The aim of requirement validation is to validate therequirements, i.e., check the requirements tocertify that they represent an acceptabledescription of the system, which is to beimplemented.DistinctionBetween Requirement Analysis and

Requirement Validation

Requirement analysis is concerned withrequirement as elicited from system stakeholders.

The requirements are usually incomplete and areexpressed in an informaland unstructured way.Requirement validation is concerned with checkinga final draft of a requirements document whichincludes all system requirements and whereknown incompleteness and inconsistency has been

removed.Different Concerns Between RequirementAnalysis and RequirementValidation Requirements analysis should

mostly be concerned with answering the questionhave we got the right requirement

Requirements validation is mostly be concernedwith answering the question RequirementsValidation Process The main problem ofrequirements validation is that there is no exiting

document, which canbe a basis for the validation. Adesign or a program may be

validatedagainst the specification. However, there is no way todemonstrate that a requirements specification iscorrect with respect to some other systemrepresentation. Specification validation, therefore,really meansensuring that the requirements document representaclear description of the system for design andimplementation and is a final check that therequirements meetstakeholder needs.


36/140

Validation Method&Requirement Reviews

Requirement reviews are the most widely usedtechnique of requirements validation. They involve agroup of people who read and analyze the

requirement, look for problems, meet to discussthese problems and agree on a set of actions toaddress the identified problem

4. Explain about RequirementManagement.

Requirements management is the process of

managing changes to a systems requirements.Normally there is more than 50% of a systemsrequirements which will be modified before it isput into service.The Principal Concerns ofRequirements Management

The principal concerns of requirements

management are: To manage

changes to agreed requirementsTo manage the relationship

between requirements, andTo manage the dependencies betweenthe requirements document and other

documents produced during thesystems and software engineeringprocess.FactorsLeading to Requirements Change

The following factors are main causes leading to

requirement changes: Requirements errors,

conflicts and inconsistencies

Evolvingcustomers/end-user knowledge of thesystemTechnical, schedule or costproblemsChangingcustomerprioritiesEnvironmentalchangesOrganisation al changes.Stable and VolatileRequirements. Requirements changes occur whilethe requirements are being elicited, analysed andvalidated and after the system has gone into service.


37/140

Although change is inevitable, it is usually thecase that some requirements are more stablethan others. Stable requirements are concerned

with the essence of a system and its applicationdomain. They change more slowly than volatilerequirements.

Volatile requirements are specific to theinstantiation of the system in a particular

environment andfor aparticular customer. Volatile requirements

are easily changed. Generally, there are fourtypes of volatile requirements:

Mutable requirements - which change because ofchanges to the environment in which the system isoperating.Emergent requirements - which cannot becompletely defined when the system is specified butwhichemerge as the system is designed

and implemented. Consequentialrequirements - which are based on assumptionsabout how the system will be used. When thesystem is put to use, some of these assumptions

will be wrong. Users need to adapt to the system andfind new ways to use its functionality.Compatibilityrequirements - which depend on otherequipment or processes. As this equipment changes,these requirements also evolve. RequirementIdentification and Storage

5.What is benefits of prototypingin the software

1.Proce

ss.

The benefits of developing a prototype earlyin the software process are :

(1)Misunderstandings between softwaredevelopers and users may be identified as thesystem functions are demonstrated.


38/140

(2)Missing user services may be detected.(3)Difficult-to-use or confusing user

services may be identified andrefined.

(4)Software development staff may findincomplete and/or

inconsistent requirements as theprototype is developed.(5)A working, albeit limited, system is

available quickly to demonstrate thefeasibility and usefulness of the application tomanagement.

(6)The prototype serces as a basisfor writing the specification for aproduction quality system.

Software prototypes also have

other uses: (1)User training(2)System testing

The final stage of the process is prototype

evaluation.There are non- technical managerialproblems which may make itdifficult to use prototyping in some organizations.

Prototyping in thesoftware process

One way of tackling this difficulty is to use anevolutionary approach to systems development.Alternatively, a deliverate decision mignt be made tobuild a 'throw-away' prototype to helprequirements analysis and validation.

There is an important difference between theobjectives of evolutionary and throw-awayprogramming:

(1)The objective of evolutionaryprototyping is to deliver a workingsystem to end-users.

(2)The objective of throw-away prototyping is tovalidate or derive the


39/140

system requirements.

Evolutionaryprototyping

There are three main problems with evolutionaryprototyping which are particularly important whenlarge, long-lifetime systems are to bedeveloped.Difficulties do not mean that evolutionaryprototyping should berejected.

Throw-awayprototyping

This approach extends the requirements analysisprocess with the intention of reducing overall ligecycle costs.Customers and end-users should resistthe temptation to turn the throw-away prototypinginto a delivered system that is put into use.

7.Explain about User interfacePrototyping.

Interface generation systems may be based onuser interface

management systems which provide basic userinterface functionality such as menu selection,object display and so on. From a softwareengineering point of view, it is important to realizethat user interface prototyping is an essential part ofthe process.

A prototype can be thought of as a model of thedesign of some system or artifact. By model,Wedont mean scale model or miniature version of thedesign.A prototype is built to resemble the realthing, with at least some of the functionality that is

intended for the final design.

It is an idea which has always been used in thefield of

engineering. For example, when a new car or

aeroplaneis being

developed, there comes a stage when the paperdesign can be taken no further until certain ideahave been tried out for real and the informationfrom these trials can be fed back to refine thedesign. So, a prototype is


40/140

built - a full size car or plane, or whatever - which willinclude most of the functions that it is intended thatthe final product will have. This prototype is then putto the test to see how well the new design ideaswork, what needs further improvement, what needscomplete replacement, and so on.

The same concept can be used in designing softwareinterfaces, though the timing and purpose of buildinga prototype is slightly different from the engineeringexamples. When developing a new aeroplane,say, the designers usually have a fairly good ideafrom the outset of what they want the plane to looklike, how they would want it to perform, what size itshould be, and so on. Thus, they are likely to firstproduce, on paper, a more-or-less complete design

and from this the prototype is built. They will(hopefully, for the sake of the test pilots) bereasonably sure that theprototype will actually fly, from tests carried out onscale models in wind tunnels or, nowadays, from

computer simulations. The prototype, then, is usedto confirm the functionality of the design and,perhaps, provide information for some relativelyminor modifications to the design.

However, in HCI design, the actual user

requirements, the shape of the interface, therequired funcionality, and so on, are often notcompletely known at the outset. In this case, thedesigner will start to build a prototype system (orsystems) quite early on and use this, with samples ofusers, as a tool to find out what the userwants, how they want to operate, what kind ofscreen layout they prefer, an so on.

This method, of having users interact with

something concrete that resembles in appearance,and perhaps user requirements in order to producea specification for in functionality, the system underdevelopment issometimes the only way of collecting informationabout the system.


41/140

8. Write a short notes on Data Dictionary

Data Dictionary is also called data repositoryDocuments specific facts about the system .

The Following are the important

divisions of data flows: (i)Data

flows(ii)Data stores(iii)Processes(iv)External entities(v)Data structures (records)

(vi)Data elements (dataitems, fields)(vii)Documenting theelements

All of the items in a DFD is to be documented in theData Dictionary, also called the Data Repository. Allmajor characteristics of the items must be recordedand described. The key objective is to provide clear,comprehensive information about the system.

During the documentation process, paper-basedstandard forms or a CASE tool can be used. Varioustools are available, and Visible Analyst is a popularexample.

Documenting the data elements

Must document every data element. Exampleattributes of a data element are:

(i)Name or label(ii)Alternatename(s)

(iii)Type andlength(iv)Output format


42/140

(v)Default value(vi)Prompt, header or field caption(vii)Source(viii)Security(ix)Responsibleuser(s)

(x)Acceptable values and data validation(xi)Derivation formula(xii)Description and comments

Documenting the data flows

Must document every data flow. Exampleattributes of a data flow are:

(i)Name or label(ii)Alternate

name(s)(iii)Description

(iv)Origin(v)Record group of data elements(vi)Volume and frequency

Documenting the data stores

Must document every data store. Example attributesof a data store are: (i)Name or label(ii)Alternatename(s)(iii)Description(iv)Input data flows(v)Output data flows(vi)Record group of data elements(vii)Volume and frequency

Documenting the processes


43/140

Must document every process. Example attributesof a process are:

(i)Name or label(ii)Alternatename(s)(iii)Purpose ordescription(iv)Processnumber (v)Inputdata flows(vi)Output dataflows (vii)Processdescription

Documenting the external entities

Must document every external entity.Example attributes of a external entity are:

(i)Name orlabel(ii)Alternatename(s)(iii)Description(iv)Input dataflows (v)Outputdata flows

Documenting the records

Must document every record. Example

attributes of a

record are: (i)Name or label(ii)Alternatename(s)

(iii)Definition ordescription(iv)Record content or composition(v)Data Dictionary Reports


44/140

Data dictionary serves as a central storehouse fordocumentation Using this data, you can producemany valuable reports through data dictioanry.

9. Explain Process Description Tools and

Modular design. Process descriptiondocuments a functional primitive, usingmodular design Modular design uses threelogical structures

(i)Sequence(ii)Selection(iii)Iterati

on

Process description tools are:

(i)StructuredEnglish(ii)Decisiontables(iii)Decisiontrees

Structured English

Structured English is a subset of standard English,used to describe process logic. Use only standardsequence, selection, and iteration structuresUse indentation for readabilityUse a limited vocabularyDecision tablesProcess logic is sometimes best illustrated by adecision table where conditions and actions arelisted as rows of a table.


45/140

Every logical combination is showninitially Results then can be combined andsimplified Programmers can use decisiontables in developing code

Decision trees

A decision tree is a graphical representationthat shows a decision tables conditions, actions, andrules. Logic structure is shown horizontally Easy toconstruct and understand. Decisiontable is better in complex situations .Logical andPhysical models Sequence of models need to be

constructed during system analysis.A physical model shows how the systems

requirements are implemented.

(i)Create a physical model of the currentsystem(ii)Develop a logical model of the currentsystem

After the current system is understood, createa logical model of the new system

Logical Versus Physical Models

Four-model approach is also sometimespursued.The four models are:

Normalize a logical data model to removeimpurities that can make a database unstable,inflexible,and nonscalable. Describe a useful tool formapping data requirements to business operatinglocations.

Data analysis is a process that prepares adata model for implementation as a simple,

nonredundant, flexible, andadaptable database. The specific technique is callednormalization.

Normalization is a data analysis techniquethat organizes data attributes such that they aregrouped to form nonredundant, stable, flexible, andadaptive entities

An entity is in first normal form (1NF) ifthere are no attributes

that can have more than one value for a singleinstance of the entity. Any attributes that can havemultiple values actually describe a separate entity,possibly an entity and relationship.

An entity is in second normal form (2NF) if it isalready in 1NF

and if the values of all nonprimary key attributes aredependent on the full primary keynot just part of it.Any nonkey attributes that are dependent

on only part of the primary key should bemoved to any entitywhere that partial key is actually the full key. This

mayrequire

creating a new entity and relationship on the model.(i)Physical model of the current system (ii)Logical model of the


46/140

current system (iii)Logicalmodel of the new system(iv)Physical model of thenew system

10. Explain about Data Model

An entity is in third normal form (3NF) if it isalready in 2NF and if the values of its nonprimary

key attributes are not dependent on anyother nonprimary key attributes. Any nonkeyattributes that aredependent on other nonkey attributes must be

moved or deleted. Again, new entities andrelationships may have to be added to the datamodel.


47/140

Typ

e: A category of entities sharing common characteristics Consider

the built-in type INTEGER in Pascal (or int in C).By declaring a Pascal variable to be of typeINTEGER, we are specifying that the variable hasthe characteristics of that type:

A value (state) drawn from some set(domain)of possible values--in the case of INTEGER, asubset of the mathematical set of integers, a set ofoperations that can be applied to those values--inthe case of INTEGER, addition, multiplication,comparison for equality,etc.

2. What are the four major areas of concern in design? The

four major areas of concern in design are:

i. Data

ii. Architecture

iii. Interfaces

iv. Components

3. Define - Software design.

Suppose we declare a Pascal variable to havetype INTEGER. By that declaration, we are creatinga container in the

program's memory that, at any point in time, holds asingle value drawn from the INTEGER domain. Thecontents of this container can be operated upon bythe INTEGER operations. In a program, we candeclare several INTEGER variables: each variablemay have a different value, yet all of them have the

same set of operations.

UNIT-III

DESIGN CONCEPTS AND PRINCIPLES

1. What is meant by design?

Design is a meaningful engineering representation of

something that is to be built. It can be traced to a customer'srequirements and at the same time assessed for quality against a

set of predefined criteria.


48/140

Software design is an iterative process through which

requirements are translated into a blueprint for constructing

software.

4. Mention three characteristics for the evaluation of a gooddesign.

The three characteristics suggested by Mc Glaughlin serves as a

guide for the evaluation of a good design. They are:

i. The design must implement all of the explicit requirements

contained in the analysis model and must accommodate all the

implicit requirements desired by the customer.

.ii. The design must be an understandable guide for those who

generate the code and for those who test and subsequently supportthe software.

iii. The design should provide a complete picture of he software,

addressing the data, functional and behavioral domains from an


49/140

implementation perspective.

5. Mention any eight software design principles.

The eight software design principles are:

.i. The design should be traceable to the analysis model.

ii. The design should not reinvent the wheel.

iii. The design should exhibit uniformity and integration.

IV. The design should be structured to accommodate change. v.

The design process should not suffer from "tunnel vision" . vi.

Design is not coding, coding is not design.

vii. The design should be assessed for quality as it is being

created.

viii. The design should be reviewed to minimize semantic errors.

6. Explain the terms: Procedural abstraction, data abstraction

and control abstraction.

A "procedural abstraction" is a named sequence of instructions

that has a specific and limited function.

Eg: The word "Open the door" implies walk to the door,

reach out, grasp knob, turn knob pull door etc.

A "data abstraction" is a named collection of data that describes a

data object.

Eg : doo_. The word door encompasses a set of attributes

like door type, swing direction, opening mechanism, etc.

Control abstraction implies a program control mechanism withoutspecifying internal details.

Eg : Synchrpnization semaphore.

7. Are abstraction and refinement complementary concepts?

Justify.

Yes, abstraction and refinement are complementary

concepts. Abstraction enables a designer to specify procedure and

data and yet suppress low-level details. Refinement helps thedesigner to reveal low-level details as design progresses.

8. How can we evaluate a design method to determine., if it

will lead to effective

modularity?

Meyer defines five criteria that enable us to evaluate a

design method with respect to its ability to define an effective

modular system.

i. Modular decomposability: If a design method provides

mechanism for decomposing problems, it will reduce the

complexity of the overall problem.

ii. Modular compos ability: If a design, method enables

reusable design components to be assembled into a new system, it


50/140

will yield a modular solution that does not reinvent the wheel.

iii. Modular understandability: If a module is understood, it

is easy to build and change.

iv. Modular continuity: If small changes to software

requirements results in change in individual modules rather than

system wide changes, the impact of change-induced tlide effects

will be minimized.

v. Modular protection: If an aberrant condition occurs

within a module and .its effects re constrained within that module,

the impact of error - induced side effects will be minimized.

9. Define - Software architecture.Software architecture is defined as the overall structure of

the software and the ways in which that structure provides

conceptual integrity for a system.

10. Describe the properties that should be specified as

part of the architectural design.

The properties are: .

i. Structural properties: It defines the components of a system andthe manner in which those components are packaged and interact

with one another.

ii. Extra functional properties: The design description should address

how the design- architecture achieves requirements for

performance, capacity, reliability, security, adaptability and other

system characteristics.

iii. Families of related systems:, The design should include the

repeatable patterns commonly. encountered in the design. The

design should have the ability to reuse architectural building

blocks.

11. List all the five models in which the architectural design

can be represented.

The architectural design can be represented using one or

more-of a number of different models namely,

i. Structural model

ii. Framework model

iii. Dynamic model

iv. Process modelv. Functional model

12. What is meant by control hierarchy?

Control hierarchy is the organization of program

components and implies a hierarchy of control.

13. Distinguish between fan in and fan out.

Fan-in Fan-outFan-out is a measure of the number of modules that are direct1y

controlled by another module.

Fan-in indicates how many modules directly control a givenmodule


51/140

14. Explain the terms: Visibility and Connectivity.

Visibility indicates the set of program components that may

be invoked or used as data by a given component, even when this

is accomplished indirectly.

Connectivity indicates the set of components that are

directly invoked or used as a data by a given component.

15. What are the benefits of horizontal partitioning?

The benefits of horizontal partitioning are:

i. Software is easy to test

ii. Software is easy to maintain iii. Propagation of fewer side

effects iv. Software is easy to extend.

16. What are the two types of structural partitioning? Explain.

The two types of structural partitioning are:

i. Horizontal partitioning

ii. Vertical partitioning

Horizontal partitioning defines separate branches of the

modular hierarchy for each major program function.

Vertical partitioning suggests that the control and workshould be distributed top-down in the program structure.

17. What is a data structure?

Data structure is a representation of the logical relationshipamong individual elements of data. It dictates

The organization. method of access, degree of associativity and

processing alternatives for information.

18. Explain the qualitative criteria for measuring

independence.

Independence is measured using two qualitative criteria

i. Cohesion ii. Coupling

Cohesion is a measure of relative functional strength of a

module.

Coupling is a measure of relative interdependence among

modules.

19. Explain the terms: coincidentally cohesive, logicallycohesive, temporal cohesion.

Modules that perform a set of tasks that relate to each other

loosely are termed as coincidentally cohesive.

A module that performs that are logically related is logically

cohesive.

When a module contains tasks that are related by the fact

that all must be executed with the same span of time, the module

exhibits temporal cohesion.

20. When do we say procedural and communication cohesion

are present?

When processing elements of a module are related and must


52/140

be executed in a specific order, procedural cohesion exists.

When all processing elements concentrate on one area of

data structure, communicational cohesion is present.

21. Explain the following.

i. Data coupling

ii. Stamp coupling

iii. Control coupling

i. Data coupling is exhibited when a simple data is passed between

modules, i.e., a one-to-one correspondence of items exist.

ii. Stamp coupling is found when a portion of a data structure is

passed via a module interface.

iii. Control coupling exists when a 'control flag' .is passed

between two modules.

22. Explain the following:

i. External coupling

ii. Common coupling

iii. Content coupling

i. When modules are tied to an environment external to software,

external coupling is found.

ii. When a number of modules reference a global data area,

common coupling exists.

iii. Content coupling occurs when one module makes use of data

or control information maintained within the boundary of

another module.

23. Mention any four design heuristics.

The four design heuristics are:

i. Evaluate the "first iteration" of the program structure to reduce

coupling and improve cohesion.

ii. Attempt to minimize structures with high fan-out; strive for fan-

in as depth increases.'

iii. Keep the scope of effect of a module within the scope of

control of that module.

iv. Evaluate module interfaces to reduce complexity andredundancy and improve consistency.

24. With a neat diagram, describe the design model.

Data design transforms information domain model created

during analysis into data structures that will be required to


53/140

implement the software.

Architectural design defines relationship between major

structural elements of the software.

Interface design describes how the software communicates within

itself, with systems that inter-operate with it, and with humanswho use it.

Component level design transforms structural elements of the

software architecture into a procedural description of software

components.

25. What is the purpose of a cross reference in thedesign specification?

The purpose of cross reference in design specification is :

i. To establish that all requirements are satisfied by the software

design.

ii. To indicate which components are critical to the

implementation of specific requirements.

26. Why is software architecture important?

Software architecture is important for the following reasons:

i. Representations of software architecture are an enabler forcommunication between all parties interested in the development

of a computer - based system.

ii. The architecture highlights early design decisions that will have a

profound impact on all software engineering work.

iii. Architecture constitutes a relatively, small, intellectually

graspable model of how the system is structured and how its

components work together.

27. List the characteristics that differentiate between a data

ware' house and a database.

.The characteristics that differentiate between a data ware houseand a database are

i. Subject orientation

ii. Integration

iii. Time variancy

iv. Non volatility

28. Mention any four principles applicable to data design.

The four principles applicable to data design are:

i. The systematic analysis principles applied to function and

behavior should also be applied to data.

ii. All data structures and the operations to be performed on each


54/140

should be identified.

iii. A data dictionary should be established and used to define both

data and program design.

iv. Low-level data design decisions should be deferred until late in

the design process.

29. What is an architectural style?

The software built for computer-based systems exhibits one

of manly architectural styles. Each style describes a system

category that encompasses,

i. A set of components - that perform a function required . by a

system.

ii. A set of connectors that enable communication coordination

and co-operation among components.

iii. Constraints that define how components can be integrated to

form the system

iv. Semantic models that enable the designer to understand the

overall properties of a system by analyzing the known properties

of its constituent parts.

30. List any four architectural styles.

The four architectural styles are:

i. Data - centered architectures

ii. Data - flow architectures

iii. Call and return architectures

iv. Object - oriented architectures.

31. Define - Transform Mapping.

Transform Mapping is a set of design steps that allows a

Data Flow Diagram (DFD) with transform flow characteristics to

be mapped into a specific architectural style.

32. Explain - Transform Flow.

Information enters the system along the paths that transform

external data into internal form. These paths are identified as

incoming flow. At the kernel of the software, a

transition occurs. Incoming data are passed through a

transform center and begin to move along paths that HOW lead

"out" of the software. Data moving along these paths are called

outgoing flow.

The overall flow of data occurs in a sequential manner.

When a segment of a data flow diagram exhibits these

characteristics, transform flow is present.33. Describe - Transaction Flow.

The fundamental model is transform flow. The information

flow is characterized by a single data item called a transaction,

that triggers other data flow among one of many paths. When a

data flow diagram takes this form, transaction flow is present.

34. List out the design steps in transform mapping.


55/140

The design steps in transform mapping are :,

i. Review the fundamental system model.

ii. Review and refine data flow diagrams for the software.

iii. Determine whether the DFD has transform or

transaction flow characteristics.

iv. Isolate the transform center by specifying incoming and

outgoing flow boundaries. .

v. Perform "first - level factoring"

vi. Perform "second - level factoring"

vii. Refine the first iteration architectural using design heuristicsfor improved software quality.

35.What happens after the architecture has been created?

After the architecture 'has been developed and refined, the

following tasks must be completed:

i. A processing narrative must be developed for each module.

ii, An interface description is provided for each module.

iv. Local and global data structures are defined.

v. All design restrictions and limitations are noted.

vi. A set of design reviews are conducted.

vii. Refinement is considered.

36. Explain User Interface Design.

User Interface Design creates an effective communication

medium between a human and a computer. Following a set of

interface design principles, design iden