UNIT II SOFTWARE REQUIREMENTS

Functional and non-functional - user – system –requirement engineering process– feasibility studies – requirements – elicitation – validation and management –software prototyping – prototyping in the software process – rapid prototyping techniques – user interface prototyping -S/W document. Analysis and modeling –data, functional and behavioral models – structured analysis and data dictionary.

Key points: 

Functional requirements of the system



Non-functional requirements of the system, and



Goals of implementation

Functional and non-functional Functional requirements capture the intended behavior of the system-or what the system will do. This behavior may be expressed as services, tasks or functions the system is required to perform. Non-functional Requirements. Non-functional requirements or system qualities, capture required properties of the system, such as performance, security, maintainability, etc.-in other words, how well some behavioral or structural aspect of the system should be accomplished.

Requirements Engineering 

Must be adapted to the needs of a specific process, project, product, or people doing the work.



Begins during the software engineering communication activity and continues into the modeling activity.



In some cases requirements engineering may be abbreviated, but it is never abandoned.



It is essential that the software engineering team understand the requirements of a problem before the team tries to solve the problem.

What is a requirement?  It may range from a high-level abstract statement of a service or of a system Constraint to a detailed mathematical functional specification This is inevitable as requirements may serve a dual function

• May be the basis for a bid for a contract - therefore must be open to interpretation • May be the basis for the contract itself - therefore must be defined in detail • Both these statements may be called requirements Types of requirement  User requirements: Statements in natural language plus diagrams of the services the System provides and its operational constraints. Written for customers System requirements: A structured document setting out detailed descriptions of the system services. Written as a contract between client and contractor.

Requirements Engineering Tasks 

Inception (software engineers use context-free questions to establish a basic understanding of the problem, the people who want a solution, the nature of the solution, and the effectiveness of the collaboration between customers and developers)



Elicitation (find out from customers what the product objectives are, what is to be done, how the product fits into business needs, and how the product is used on a day to day basis)



Elaboration (focuses on developing a refined technical model of software functions, features, and constraints using the information obtained during inception and elicitation)



Negotiation (requirements are categorized and organized into subsets, relations among requirements identified, requirements reviewed for correctness, requirements prioritized based on customer needs)



Specification (written work products produced describing the function, performance, and development constraints for a computer-based system)



Requirements validation (formal technical reviews used to examine the specification work products to ensure requirement quality and that all work products conform to agreed upon standards for the process, project, and products)

Requirements Management 

Set of activities that help project team to identify, control, and track requirements and changes as project proceeds



Many of these activities are identical to those that make up the software configuration management (SCM) process



Requirements are first identified, tagged with a unique identifier and classified by type (functional, data, behavioral, interface, or output)



Traceability tables (e.g., features, source, dependency, subsystem, interface) are developed and updated any time a requirement is modified)



Database systems are invaluable in helping software teams track requirement changes

Initiating Requirements Engineering Process 

Identify stakeholders



Recognize the existence of multiple stakeholder viewpoints



Work toward collaboration among stakeholders



These context-free questions focus on customer, stakeholders, overall goals, and benefits of the system



o

Who is behind the request for work?

o

Who will use the solution?

o

What will be the economic benefit of a successful solution?

o

Is there another source for the solution needed?

The next set of questions enable developer to better understand the problem and the customer's perceptions of the solution



o

How would you characterize good output form a successful solution?

o

What problem(s) will this solution address?

o

Can you describe the business environment in which the solution will be used?

o

Will special performance constraints affect the way the solution is approached?

The final set of questions focuses on communication effectiveness o

Are you the best person to give "official" answers to these questions?

o

Are my questions relevant to your problem?

o

Am I asking too many questions?

o

Can anyone else provide additional information?

o

Should I be asking you anything else?

Eliciting Requirements 

Collaborative requirements gathering o

Meetings attended by both developers and customers

o

Rules for preparation and participation are established

o

Flexible agenda is used

o

Facilitator controls the meeting

o

Definition mechanism (e.g., stickers, flip sheets, electronic bulletin board) used to gauge group consensus

o

Goal is to identify the problem, propose solution elements, negotiate approaches, and specify preliminary set of solutions requirements



Quality function deployment (QFD) o

Identifies three types of requirements (normal, expected, exciting)

o

In customer meetings function deployment is used to determine value of each function that is required for the system

o

Information deployment identifies both data objects and events that the system must consume or produce (these are linked to functions)

o

Task deployment examines the system behavior in the context of its environment

o

Value analysis is conducted to determine relative priority of each requirement generated by the deployment activities



User-scenarios o

Also known as use-cases, describe how the system will be used

o

Developers and users create a set of usage threads for the system to be constructed

Elicitation Work Products 

Statement of need and feasibility



Bounded statement of scope for system or product



List of stakeholders involved in requirements elicitation



Description of system's technical environment



List of requirements organized by function and applicable domain constraints



Set of usage scenarios (use-cases) that provide use insight into operation of deployed system



Prototypes developed to better understand requirements

Software prototyping:

A model of s/w to be built is called a prototype. A prototype is constructed for customer and developer assessment. (i) Selecting a prototyping approach:

* The prototyping paradigm can be either close ended or open ended * The close ended approach also called throw away prototyping. Using this prototype serves as a rough demonstration of requirements. * An open ended approach, called evolution of the prototyping uses the prototype as the first part of

an analysis activity that will be continued into design and construction. * Before a close ended or open ended approach can be chosen, it is necessary to determine whether the system to be built is amenable to prototyping. * Prototyping factors are application area, application complexity, customer characteristics and project characteristics.

(ii) Prototyping s/w process: * In common with other types of s/w development, the prototyping process follows a define s/w process model. * This model indicated the processes and tasks, which have to be performed during development of the prototype. * Process model device for this particular approach comprise the following stages. 1. Analysis requirements: This involved the developer understanding the content and nature of the customer’s initial requirements. 2. Prototype design: Here the developer should choose a suitable implementation approach for which to develop the prototype. Also a design is derived for the prototype based upon the results of analysis phase. 3. Prototype construction: This stage involves actual coding of the prototype

Rapid prototyping:

* An evolutionary s/w prototyping process is produced based on a requirement analysis of the customer’s problem. This analysis is needed to ensure the initial version of the prototype is close enough to what the customer need to enable them to provide meaningful evaluations and criticism. * Each succeeding version of the prototype is produced based upon an analysis of the customer’s reaction to the demonstration of the previous version. * Delivered products are delivered from the prototypes that are accepted by the customers via an optimal optimization process. * Maintenance activities are sparked by new customer’s requirements, which restart the prototyping process and extent the series of prototypes until a new stable point is reached. * The spiral model is well known because it combines the common knowledge of water fall model, incremental method and process model work into an attractive notation, even with less specific variation of the process. * Some advantage of this approach are that

prototype of different aspects of the system can be

developed concurrently and independently, that each fragment is relatively small, simple and easy to change, and that different tools and environments can be used for different aspects. The last property

can be important in the short term, if tools are available for solving different parts of the problem, but these tools have not been integrated together into a comprehensive prototyping environment.       User interface prototyping  Interface generation systems may be based around user interface management systems which provide basic user interface functionality such as menu selection, object display and so on. From a software engineering point of view, it is important to realize that user interface prototyping is an essential part of the process. It is impossible to pre-specify the look and feel of a user interface in an effective way UI development consumes an increasing part of overall system development costs. User interface generators may be used to ‘draw’ the interface and simulate its functionality with components associated with interface entities. Web interfaces may be prototyped using a web site editor

Software Document  It is the agreed statement of the system requirement.  It should be organized so that it can be used by both system customers and software developers.  SRS is the official statement of what is required of the system developers. SRS includes 1. User requirements for a system 2. Detailed specification of the system requirements Six Requirements of SRS: It should specify only the external system behavior. It should specify the constraints on the implementation. It should be easy to change. It should serve as a reference tool for system maintainers It should record the forethought about the lifecycle of the system. It should characterize acceptance responses to undefined events

Analysis Model



Intent is to provide descriptions of required information, functional, and behavioral domains for computer-based systems



Analysis Model Elements o

Scenario-based elements (describe system from user perspective)

o

Class-based elements (relationships among objects manipulated by actors and their attributes)

o

Behavioral elements (depict system and class behavior as states and transitions between states)

o

Flow-oriented elements (shows how information flows through the system and is transformed by the system functions)





Many different representations can be used to depict the analysis model o

Use-case diagrams

o

Activity diagrams

o

Class diagrams

o

State diagram

o

Data flow diagram (DFD)

Analysis Pattern Template o

Name

o

Intent

o

Motivation

o

Forces and context

o

Solution

o

Consequences

o

Design

o

Known use examples

o

Related patterns

Negotiating Requirements 

Negotiation activities o

Identification of system key stakeholders

o

Determination of stakeholders' "win conditions"

o

Negotiate to reconcile stakeholders' win conditions into "win-win" result for all stakeholders (including developers)



Key points o

It's not a competition

o

Map out a strategy

o

Listen actively

o

Focus on other party's interests

o

Don't let it get personal

o

Be creative

o

Be ready to commit

Requirement Review (Validation) 

Is each requirement consistent with overall project or system objective?



Are all requirements specified at the appropriate level off abstraction?



Is each requirement essential to system objective or is it an add-on feature?



Is each requirement bounded and unambiguous?



Do you know the source for each requirement?



Do requirements conflict with one another?



Is the requirement achievable in the proposed technical environment for the system or product?



Is each requirement testable?



Does the requirements model reflect the information, function, and behavior of the system to be built?



Has the requirements model been partitioned in a way that exposes more detailed system information progressively?



Have all the requirements patterns been properly validated and are they consistent with customer requirements?

The analysis model is the first technical representation of a system. Analysis modeling uses a combination of text and diagrams to represent software requirements (data, function, and behavior) in an understandable way. Building analysis models helps make it easier to uncover requirement inconsistencies and omissions. Two types of analysis modeling are commonly used: structured analysis and object-oriented analysis. Scenario-based modeling represents the system from the user's point of view. Flow-oriented modeling shows how data are transformed inside the system by processing functions. Class-based modeling defines objects, attributes, and relationships. Behavioral modeling uses state transition diagrams to show the impact of events on the system states. Analysis work

products

must

be

Analysis Model Guidelines

reviewed

for

completeness,

correctness,

and

consistency.



Analysis products must be highly maintainable, especially the software requirements specification.



Problems of size must be dealt with using an effective method of partitioning.



Graphics should be used whenever possible.



Differentiate between the logical (essential) and physical (implementation) considerations.



Find something to help with requirements partitioning and document the partitioning before specification.



Devise a way to track and evaluate user interfaces.



Devise tools that describe logic and policy better than narrative text.

Analysis Model Objectives 

Describe what the customer requires.



Establish a basis for the creation of a software design.



Devise a set of requirements that can be validated once the software is built.

Analysis Model Rules of Thumb 

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



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



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



Minimize coupling throughout the system.



Be certain the analysis model provides value to all stakeholders.



Keep the model as simple as possible.

Domain Analysis Activities 

Define the domain to be investigated



Categorize the items extracted from the domain



Collect a representative sample of applications in the domain



Analyze each application in the sample o

Identify candidate reusable objects

o

Indicate reasons the objects may be reused

o

Define adaptations of the objects that may be reused

o

Estimate percentage of applications in the domain that might make reuse of the objects

o

Identify objects by name and use configuration management techniques to control them



Develop an analysis model for the objects

Structured Analysis Model Elements 

Data dictionary - contains the descriptions of all data objects consumed or produced by the software



Entity relationship diagram (ERD) - depicts relationships between data objects



Data flow diagram (DFD) - provides an indication of how data are transformed as they move through the system; also depicts functions that transform the data flow (a function is represented in a DFD using a process specification or PSPEC)



State diagram (SD) - indicates how the system behaves as a consequence of external events, states are used to represent behavior modes. Arcs are labeled with the events triggering the transitions from one state to another (control information is contained in control specification or CSPEC)

Data Modeling Elements (ERD) 

Data object - any person, organization, device, or software product that produces or consumes information



Attributes - name a data object instance, describe its characteristics, or make reference to another data object



Relationships - indicate the manner in which data objects are connected to one another

Cardinality and Modality (ERD) 

Cardinality - in data modeling, cardinality specifies how the number of occurrences of one object are related to the number of occurrences of another object (1:1, 1:N, M:N)



Modality - zero (0) for an optional object relationship and one (1) for a mandatory relationship

Functional Modeling and Information Flow (DFD) 

Shows the relationships of external entities, process or transforms, data items, and data stores



DFD's cannot show procedural detail (e.g., conditionals or loops) only the flow of data through the software



Refinement from one DFD level to the next should follow approximately a 1:5 ratio (this ratio will reduce as the refinement proceeds)



To model real-time systems, structured analysis notation must be available for time continuous data and event processing (e.g., Ward and Mellor or Hatley and Pirbhai)

Behavioral Modeling (STD) 

State transition diagrams represent the system states and events that trigger state transitions



STD's indicate actions (e.g., process activation) taken as a consequence of a particular event



A state is any observable mode of behavior



Hatley and Pirbhai control flow diagrams (CFD) and UML sequence diagrams can also be used for behavioral modeling

Creating Entity Relationship Diagrams 

Customer asked to list "things" that application addresses, these things evolve into input objects, output objects, and external entities



Analyst and customer define connections between the objects



One or more object-relationship pairs is created for each connection



The cardinality and modality are determined for an object-relationship pair



Attributes of each entity are defined



The entity diagram is reviewed and refined

Creating Data Flow Diagram 

Level 0 data flow diagram should depict the system as a single bubble



Primary input and output should be carefully noted



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



Label all arrows with meaningful names



Information flow must be maintained from one level to level



Refine one bubble at a time



Write a PSPEC (a "mini-spec" written using English or another natural language or a program design language) for each bubble in the final DFD

Creating Control Flow Diagrams 

Begin by stripping all the data flow arrows form the DFD



Control items (dashed arrows) are added to the diagram



Add a window to the CSPEC (contains a SD that is a sequential specification of the behavior) for each bubble in the final CFD

Object-Oriented Concepts Objects - encapsulate both data (attributes) and data manipulation functions (called methods, operations, and services) Class - generalized description (template or pattern) that describes a collection of similar objects Super class - a collection of objects Subclass - an instance of a class Class hierarchy - attributes and methods of a super class are inherited by its subclasses Messages - the means by which objects exchange information with one another Inheritance - provides a means for allowing subclasses to reuse existing super class data and procedures; also provides mechanism for propagating changes Polymorphism - a mechanism that allows several objects in an class hierarchy to have different methods with the same name (instances of each subclass will be free to respond to messages by calling their own version of the method) Object-Oriented Analysis Model Elements Scenario-based - depict how the user interacts with the system (use-case diagram) and the sequence of activities that occur during software use (activity diagrams and swim lane diagrams) Class-based - model the system objects, operations, class relationships (class diagram) Behavioral - depict how external events change the state of the system or the system classes (state diagram and sequence diagrams) Flow-oriented - represent the system as an information transform and depict how data objects are transformed as they flow through system function (dataflow diagram) Data Dictionary Contents

Name - primary name for each data or control item, data store, or external entity Alias - alternate names for each data object Where-used/how-used - a listing of processes that use the data or control item and how it is used (e.g., input to process, output from process, as a store, as an external entity) Content description - notation for representing content Supplementary information - other data type information, preset values, restrictions, limitations, etc. Data dictionary It is the alphabetic list of the names which are included in the different models of a system. The data dictionary has the named entity and its associated description. Data dictionary are generally useful when developing system models and used to manage all information from all types of system model Advantages Mechanism for name management. It serves as a store of organizational information that can link analysis, design, implementation and evolution.

Review Questions: 1. What is known as functional requirements?  Statements of services the system should provide how the system should react to particular inputs and how the system should behave in particular situations. Describe functionality or system service These services depend on o the type of software being developed o the expected users of the software Functional user requirements may be high-level statements of what the system should do; Functional system requirements should describe the system services in detail. Problems arise when

requirements are not precisely stated. Ambiguous requirements may be interpreted in different ways by developers and clients. Examples: The user shall be able to use an existing exam. Requirements should be both complete and consistent.  Complete o They should include descriptions of all required functionality  Consistent o There should be no conflicts or contradictions in the descriptions of the system functions 2. What are the types of non-functional requirements?  These define system properties and constraints e.g. reliability, response time and storage requirements. Constraints are I/O device capability, system representations, etc. Process requirements may also be specified mandating a particular CASE system, programming language or development method. Types of Non-Functional Requirements 1. Product requirements 2. Organisational requirements 3. External requirements 1. Product Requirements  Requirements which specify that the delivered product must behave in a particular way e.g. execution speed, reliability, etc.  To specify product behavior Examples: How fast the system must execute and how much memory it requires. 2. Organizational Requirement  Requirements which are a consequence of organisational policies and procedures e.g. process standards used, implementation requirements, etc.  Derived from polices and procedures in the customer’s and developer’s organisation 3. External Requirements  Requirements which arise from factors which are external to the system and its development process e.g. interoperability requirements, legislative requirements, etc.  It covers all requirements. Define how the system interact with systems in other organizations Examples: System shall not disclose any personal information about customers apart from their name and reference number to the operators of the system 4. What are the problems arise in user requirements. How can it solve?

Should describe functional and non-functional requirements in such a way that they are understandable by system users who don’t have detailed technical knowledge. User requirements are defined using natural language, tables and diagrams as these can be understood by all users. Problems with natural language  Lack of clarity, ambiguity

•Precision is difficult without making the document difficult to read  Requirements confusion

• Functional and non-functional requirements tend to be mixed-up  Requirements amalgamation

• Several different requirements may be expressed together Requirement problems 1. Database requirements includes both conceptual and detailed information •

Describes the concept of a financial accounting system that is to be included in LIBSYS;

•

However, it also includes the detail that managers can configure this system - this is unnecessary at this level.

2. Grid requirement mixes three different kinds of requirement •

Conceptual functional requirement (the need for a grid);

•

Non-functional requirement (grid units);

•

Non-functional UI requirement (grid switching).

Some Guidelines for User Requirements  Invent or find a standard format and use it for all requirements.  Use language in a consistent way.  Use text highlighting (e.g., italics) to identify key parts of the requirement.  Every requirement must be verifiable.  Every requirement should be numbered for trace ability

5. What do you mean by System Requirements?  More detailed specifications of system functions, services and constraints than user requirements. Requirements may be defined operationally using a programming language (e.g. Java)  They are intended to be a basis for designing the system. They may be incorporated into the system contract. Serve as a basis for the Design

o In principle Reqs. And Design are separated (WHAT vs. HOW). Using natural language, Further Problems can arise o Leads to misunderstandings o Over flexible o Difficult to find all related requirements Alternatives to NL Specification  Structured natural language  Design description languages  Graphical notations  Mathematical specifications Notation

Description

Structured

This approach depends on defining standard forms or templates to express the

natural language

requirements specification.

Design

This approach uses a language like a programming language but with more

description

abstract features to specify the requirements by defining an operational model

languages

of the system.

Graphical

A graphical language, supplemented by text annotations is used to define the

notations

functional requirements for the system. An early example of such a graphical language was SADT. Now, use-case descriptions and sequence diagrams are commonly used .

Mathematical

These are notations based on mathematical concepts such as finite-state

specifications

machines or sets. These unambiguous specifications reduce the arguments between customer and contractor about system functionality

6. List out the general activities of requirement engineering processes?  The processes used for requirement engineering vary widely depending on the application domain, the people involved and the organisation developing the requirements. There are a number of generic activities common to all processes: 1. Feasibility study A feasibility study decides whether or not the proposed system is worthwhile A short focused study that checks If the system contributes to organisational objectives If the system can be engineered using current technology and within budget

2. Elicitation and Analysis Involves technical staff working with customers to find out about the application domain, what the services that the system should provide ,the system performance May involve end-users, managers, engineers involved in maintenance, domain experts, trade unions, etc. These are called stakeholders. Problems of requirements analysis  Stakeholders don’t know what they really want  Stakeholders express requirements in their own terms  Different stakeholders may have conflicting requirements 3. Software Requirements Specification (SRS):  The software requirement and specification focuses on what the system will do not how the system will be implemented. 4. Requirements Validation Concerned with showing that the requirements define the system that the customer really wants. Requirements error costs are high so validation is very important

5. Requirements Management Requirements management is the process of managing changing requirements during the requirements engineering process and system development New requirements emerge during the process as business needs change and a better understanding of the system is developed.

7. What are the objectives of software prototyping? Prototyping is the rapid development of a system. the boundary between prototyping and normal system development is blurred and many systems are developed using an evolutionary approach Prototyping objectives The objective of evolutionary prototyping is to deliver a working system to end-users. The development starts with those requirements which are best understood. An approach to system development where an initial prototype is produced and refined through a number of stages to the final system. The objective of throw-away prototyping is to validate or derive the system requirements. The prototyping process starts with those requirements which are poorly understood. A prototype which is usually a practical implementation of the system is produced to help discover requirements problems and then discarded. The system is then developed using some other development process.

Uses of system prototypes  The principal use is to help customers and developers understand the requirements for the system o Requirements elicitation. Users can experiment with a prototype to see how the system supports their work. o Requirements validation. The prototype can reveal errors and omissions in the requirements.  Prototyping can be considered as a risk reduction activity which reduces requirements risks Prototyping benefits  Misunderstandings between software users and developers are exposed  Missing services may be detected and confusing services may be identified  The system can support user training and system testing.

8. What are the techniques used in Rapid proto typing? Various techniques may be used for rapid development. Dynamic high-level language development Database programming Component and application assembly These are not exclusive techniques - they are often used together Visual programming is an inherent part of most prototype development systems Dynamic high-level languages  Languages which include powerful data management facilities. Need a large run-time support system. Not normally used for large system development  Some languages have an integrated support environment whose facilities may be used in the prototype. Database programming languages  Domain specific languages for business systems based around a database management system. it include a database query language, a screen generator, a report generator and a spreadsheet.  May be integrated with a CASE toolset. Cost-effective for small to medium sized business systems Component and application assembly Prototypes can be created quickly from a set of reusable components plus some mechanism to ‘glue’ these components together. The composition mechanism must include control facilities and a mechanism for component communication.

The system specification must take into account the availability and functionality of existing components.

9. Write short notes on class-based modeling. The following section describes the representation of class based modeling in detail.  Identifying analysis classes  Specifying attributes  Defining operation  Class responsibility collaborator  Associations and dependencies  Analysis packages 1. Identifying Analysis Classes An analysis class represents themselves in one of the following ways. External entities, Things, Occurrences or events, Structures, Places, Organizational units, In order to identify the classes want to find out the nouns in the statement. 2. Specifying Attributes Attributes describe a class that has been selected for inclusion in the analysis model. Attributes are also called as properties. Properties represent the state of an object. 3. Defining Operations Operations define the behavior of an object. It can be divided into four broad categories.Operations that manipulate data in some way 4. Class Responsibility – Collaborator (CRC) Modeling A CRC model is a simple means for identifying and organization of the classes. The cards are divided into 3 sections. class name,Description,Responsibility and description. 5. Collaborations Classes fulfill their responsibilities in one of the two ways. A class can use its own operations to manipulate its own attributes. A class can collaborate with other classes .Collaborations identify relation between classes 6. Responsibilities Guidelines for allocating responsibilities to classes. Each responsibility should be stated as generally as possible. Responsibilities should be shared among related classes, when appropriate. 7. Associations and Dependencies  Two analysis classes may be related to one another. These relations are known as associations. An association may be further defined by indicating multiplicity.  In that situation a client class depends on the server class in some way. 8. Analysis Packages

 An important part of analysis modeling is categorization.i.e.various elements of this model are categorized in a manner that packages them a grouping- called an analysis package

10. What is the role of software document and data dictionary? It is the agreed statement of the system requirement. It should be organized so that it can be used by both system customers and software developers. SRS is the official statement of what is required of the system developers. SRS includes 1. User requirements for a system 2. Detailed specification of the system requirements. How SRS used for various users?  FOR SYSTEM CUSTOMERS: o To specify the requirements and read them to check that they meet their needs.  FOR MANAGERS: o To plan the system development process.  FOR SYSTEM ENGINEERS: o Use the requirement to understand what system is to be developed.  FOR SYSTEM TEST ENGINEERS: o Use the requirements to develop validation tests for the system.  FOR SYSTEM MAINTENANCE ENGINEERS: o To understand the system and relationship between its parts. DATA DICTIONARY It is the alphabetic list of the names which are included in the different models of a system.Descriptions of the entities, relationships and attributes are also included. Advantages  Support name management and avoid duplication;  Many CASE workbenches support data dictionaries.  It serves as a store of organizational information that can link analysis, design, implementation and evolution. STRUCTURE OF DATA DICTIONARY ENTRIES 

NAME



DESCRIPTION



TYPE



DATE

11. What are the types of analysis model? Explain one of them.

Analysis model uses the competition of text and diagrammatic forms to show the requirements for data, function and behavior. It is important to validate software requirements from a different point of view. Types of Analysis Model 1. Data modeling 2. Flow oriented modeling 3. Scenario based modeling 4. Behavioral modeling 5. Class based modeling Data modeling Data flow diagrams (DFDs) may be used to model the system’s data processing. These show the processing steps as data flows through a system. DFDs are an intrinsic part of many analysis methods. Simple and intuitive notation that customers can understand. Show end-to-end processing of data. Data Objects  Data object is a composite information  A data object description incorporates the data objects and all its attributes.  A data object encapsulates the data only Data Attributes  It defines the properties of data object  Attributes defined the properties of the data objects. Relationships  Data objects are connected to one another in different ways. For example. A person owns a car. The relationship owns an insured to drive define the relevant connections between person and car. Example Man is the Data object, Name, Sex, Age is the attributes Cardinality: It is the Data model must be capable of representing number of occurrences of objects. Modality: It is Relationship denotes the necessity of relationships between data objects.

Two Mark Questions: 1. Define Software Engineering: Software Engineering is the establishment of engineering principles in order to obtain a software which is more reliable and works more efficiently on real machines. Software Engineering is the application of a systematic disciplined quantifiable approach to the development operation and maintenance of software

.

2. Define System Engineering: Software engineering occurs as a consequence of a process called system engineering. System engineering 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. 3. Define Computer based system. Both business process engineering and product engineering attempt to bring order to the development of computer based systems. Business process engineering is focuses on a business enterprise. When a product is to be built, the process is called product engineering. 4. What are all the elements supported by the computer based system. System, Hardware, People, Database, Documentation, Procedures. 5. Define system modeling 

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



Represent the process behavior and the assumptions on which the behavior is modeled



Explicitly define the exogenous (links between constituents) and endogenous (links between constituent components) input to the model



Represent all linkages (including outputs) required to understand the view

6. Define Requirement Validation Requirements validation (formal technical reviews used to examine the specification work products to ensure requirement quality and that all work products conform to agreed upon standards for the process, project, and products) 7. List out the System Model Restraining Factors 

Assumptions



Simplifications



Limitations



Constraints



Preferences

8. List out System Engineering Hierarchy 

World view



Domain view



Element view



Detailed view

9. Define System Simulation 

If simulation capability is not available for a reactive system, project risk increases.



Consider using an incremental, iterative process model that will allow the delivery and testing of incrementally more complete products.

10. List out the Business Process Engineering Hierarchy 

Information Strategy Planning (world view)



Business Area Analysis (domain view)



Business System Design (element view - software engineers)



Construction and Integration (detailed view - software engineers)

11. Define Business Process Engineering Architectures 

Data architecture - provides framework for information needs of a business or business function



Applications architecture - those system elements that transform objects within the data architecture for some business purpose



Technology infrastructure - provides foundation for the data and application architectures

12. Define Product Engineering Hierarchy 

Requirements engineering (world view)



Component engineering (domain view)



Analysis and Design modeling (element view - software engineers)



Construction and Integration (detailed view - software engineers)

13. Define System Model Template 

User interface



Input



Process and control functions



Output



Maintenance and self test

14. Define Systems Modeling Process 

System Context Diagram (SCD) - top level node in system hierarchy used to establish the boundary between the system being implemented (system model template serves as its basis)



System Flow Diagram (SFD) - refinement of the process and control functions from SCD, derived by identifying the major subsystems and lines of information flow (precursor to Data Flow Diagram discussed in Chapter 12)



Initial SFD is becomes the top level node of a hierarchy of more successively more detailed SFD's



System Specification - developed by writing narrative description for each subsystem and definitions for all data that flow between subsystems

15. List out the System Modeling with UML Diagrams: Deployment diagram, Activity diagram, class diagram, Use case diagram. 16. Define Deployment Diagram: 

Deployment diagram - depicts hardware elements that are part of the physical architecture of the system

17. Define Activity diagram: 

Activity diagram - used to represent the procedural aspects of the system software elements, similar to a flowchart in that system functions are shown as nodes, decision points are shown as diamonds,and arrows are used to show flow through the system

18. Define Class diagram: o Class diagram - shows the class attributes and operations that may be applied to the class within the

context of the system 19. Define Use case diagram: o Use-case diagram - illustrates the manner in which an actor interacts with the system, each labeled

oval within a system boundary represents one text scenario or use-case 20. Define Requirements Engineering 

Must be adapted to the needs of a specific process, project, product, or people doing the work.



Begins during the software engineering communication activity and continues into the modeling activity.



In some cases requirements engineering may be abbreviated, but it is never abandoned.



It is essential that the software engineering team understand the requirements of a problem before the team tries to solve the problem.

21. Requirements Engineering Tasks Inception, Elicitation, Elaboration, Negotiation, Specification, Validation. 22. Define Inception: Inception (software engineers use context-free questions to establish a basic understanding of the problem, the people who want a solution, the nature of the solution, and the effectiveness of the collaboration between customers and developers) 23. Define Elicitation: Elicitation (find out from customers what the product objectives are, what is to be done, how the product fits into business needs, and how the product is used on a day to day basis)

24. Define Elaboration: Elaboration (focuses on developing a refined technical model of software functions, features, and constraints using the information obtained during inception and elicitation) 25. Define Negotiation: Negotiation (requirements are categorized and organized into subsets, relations among requirements identified, requirements reviewed for correctness, requirements prioritized based on customer needs) 26. Define Specification: Specification (written work products produced describing the function, performance, and development constraints for a computer-based system) 27. Define Requirement Validation Requirements validation (formal technical reviews used to examine the specification work products to ensure requirement quality and that all work products conform to agreed upon standards for the process, project, and products) 28. Define Requirements Management 

Set of activities that help project team to identify, control, and track requirements and changes as project proceeds



Many of these activities are identical to those that make up the software configuration management (SCM) process



Requirements are first identified, tagged with a unique identifier and classified by type (functional, data, behavioral, interface, or output)



Traceability tables (e.g., features, source, dependency, subsystem, interface) are developed and updated any time a requirement is modified)



Database systems are invaluable in helping software teams track requirement changes 16 mark questions:

1. What is software requirement? Explain different types of requirements with examples. 2. Explain the requirement engineering process with neat diagram. 3. Write short notes on: i) Rapid prototyping techniques. ii) User interface prototyping 4. Explain the various types of requirement models with an example. 5. What is data flow oriented design? What are the components of it? Draw a detailed data flow diagram for library information system.