Requirement Gathering & Analysis PDF

❖ REQUIREMENT GATHERING & ANALYSIS Requirements of a customer play a key role in developing any software product. The task of gathering requirements and analyzing them is performed by a Systemanalyst. Collecting all the information from the customer and then analyze the collected information t...

❖ REQUIREMENT GATHERING & ANALYSIS Requirements of a customer play a key role in developing any software product. The task of gathering requirements and analyzing them is performed by a Systemanalyst. Collecting all the information from the customer and then analyze the collected information to remove all ambiguities and inconsistenciesfrom customer perception. Mainly two activities are concerned with thistask. Requirement gathering Requirement analysis Requirement gathering: It is usually the first part of any software product. Thisisthe base for the whole development effort. The goal ofthe requirement gathering activityis to collect allrelated information from the customerregarding the product to be developed. Thisis done to clearly understand the customerrequirementsso that incompleteness and inconsistencies are removed. In this phase, meeting with customers, analyzing market demand and features ofthe product are mainly focused. So, activity of market research (for competitive analysis) is done. It involves interviewing the end-users and studying the existing documentsto collect all possible information. Requirement gathering activities are: o Studying the existing documents o Interview with end users or customers o Task analysis o Scenario analysis o Form analysis o Brainstorming o Questionnaires o Group discussion Requirement analysis: The goal ofthe requirement analysis activity is to clearly understand the exact requirements of the customers. IEEEdefinesrequirement analysis as(1) the process ofstudying user needs and (2) The process ofstudying and refining system hardware orsoftware requirements. Requirement analysis helpsto understand, interpret, classify, and organize the software requirementsin order to assessthe feasibility, completeness, and consistency of the requirements. Requirement Analysis & Specification Software Engineering Requirement analysis involves: Eliciting requirements:requirements are eliciting by communicating with customers and find their exact need. Analyzing requirements: requirements are then analyzed to make it complete, clear and unambiguous. Requirements recording orstoring: all the requirements are recorded in form of use cases, process specifications, natural language documents etc. System analyst should solve some of the following questions: What isthe problem? What are the inputs and outputs? What isimportant to solve? What are the complexities? What are the solutions? Change in the environment or technical aspects may affect the requirement analysis process. System analyst identifies and resolves variousrequirements problems. Forthat, analyst hasto identify and eliminate the problems of anomalies, inconsistencies and incompleteness. Anomaly isthe ambiguity in the requirement,Inconsistency contradictsthe requirements, and Incompleteness ❖ REQUIREMENT GATHERING & ANALYSIS Requirements of a customer play a key role in developing any software product. The task of gathering requirements and analyzing them is performed by a Systemanalyst. Collecting all the information from the customer and then analyze the collected information to remove all ambiguities and inconsistenciesfrom customer perception. Mainly two activities are concerned with thistask. Requirement gathering Requirement analysis Requirement gathering: It is usually the first part of any software product. Thisisthe base for the whole development effort. The goal ofthe requirement gathering activityis to collect allrelated information from the customerregarding the product to be developed. Thisis done to clearly understand the customerrequirementsso that incompleteness and inconsistencies are removed. In this phase, meeting with customers, analyzing market demand and features ofthe product are mainly focused. So, activity of market research (for competitive analysis) is done. It involves interviewing the end-users and studying the existing documentsto collect all possible information. Requirement gathering activities are: o Studying the existing documents o Interview with end users or customers o Task analysis o Scenario analysis o Form analysis o Brainstorming o Questionnaires o Group discussion Requirement analysis: The goal ofthe requirement analysis activity is to clearly understand the exact requirements of the customers. IEEEdefinesrequirement analysis as(1) the process ofstudying user needs and (2) The process ofstudying and refining system hardware orsoftware requirements. Requirement analysis helpsto understand, interpret, classify, and organize the software requirementsin order to assessthe feasibility, completeness, and consistency of the requirements. Requirement Analysis & Specification Software Engineering Requirement analysis involves: Eliciting requirements:requirements are eliciting by communicating with customers and find their exact need. Analyzing requirements: requirements are then analyzed to make it complete, clear and unambiguous. Requirements recording orstoring: all the requirements are recorded in form of use cases, process specifications, natural language documents etc. System analyst should solve some of the following questions: What isthe problem? What are the inputs and outputs? What isimportant to solve? What are the complexities? What are the solutions? Change in the environment or technical aspects may affect the requirement analysis process. System analyst identifies and resolves variousrequirements problems. Forthat, analyst hasto identify and eliminate the problems of anomalies, inconsistencies and incompleteness. Anomaly isthe ambiguity in the requirement,Inconsistency contradictsthe requirements, and Incompleteness SOFTWARE REQUIREMENT SPECIFICATION (SRS) SRS isthe output ofrequirement gathering and analysis activity. SRS is a document created by system analyst after the requirements are collected from varioussources. SRS is a detailed description of the software that isto be developed.It describesthe complete behaviorthe system. SRS describes'what' the proposed system should do without describing 'how' the software will do (what part, not how). It is working as a reference document to the developer. It provides guideline for project development,so minimizes the time and effortsforsoftware development. SRS is actually a contract between developer and end user. That helpsto dissolve the disagreement. Requirement Analysis & Specification Software Engineering The SRS translatesthe ideas of the customers(input) into the formal documents(output). The SRS document is known as black-box specification, because: In SRS, internal details ofthe system are not known (as SRS doesn'tspecify how the system will work). Only its visible external (i.e., input/output) behavioris documented. SRS documents serves as contract between customer and developer, so it should be carefully written. (Sometimes SRS is also written by the customers also). The organization of SRS is done by the system analyst. ▪ Benefits of SRS (Features of SRS): SRS providesfoundation for design work. Because it works as an input to the design phase. It enhances communication between customer and developer because user requirements are expressed in naturallanguage. Developers can get the idea what exactly the customer wants. It enables project planning and helpsin verification and validation process. Format of forms and rough screen prints can also be represented in SRS. High quality SRS reducesthe development cost and time efforts. Asit is working as an agreement between user and developer, we can get the partialsatisfaction ofthe end user forthe final product. SRS is also useful during the maintenance phase. ▪ Contents of the SRS document: An SRS should clearly document the following three things: Functional requirements of the system Functional requirements are those which are related to the technical functionality ofthe system. These are the services which the end users expect from the final product.And these are the services which a system providesto the end users. It clearly describes each of the function that the systemneedsto performalong with the input and output data set. (ii) Non-functional requirements of the system The non-functional requirements describe the characteristics ofthe systemthat can't be expressed functionally. For example, portability, maintainability, reliability, usability, security, performance etc. Non-functional requirements are requirements thatspecify criteria that can be used to judge the operation of a system in particular conditions, rather than specific behaviors. Sometimesthese requirements are also called quality attributes. (iii) Constraints(restrictions) on the system That describes what the system should do orshould not do. These are some generalsuggestionsregarding development. A constraint can be classified as: o Performance constraint o Operating system constraint Requirement Analysis & Specification Software Engineering o Economic constraint o Life cycle constraint o Interface constraint Characteristics of a good SRS: Concise SRS should contain brief and concise information regarding the project; no more detailed description ofthe system should be there. Complete Itshould be complete regarding the project,so that can be completely understood by the analyst and developers as well as customers. Consistent An SRS should be consistent through the project development. Requirements may not be conflict at the later stage. Conceptual integrity SRS should clearly provide the concepts of the system,so that can be read easily. Structured SRS should be wellstructured to understand and to implement. Black box view SRS should have black box viewmeans; there should not be much detailing ofthe project in it (only describe what part, not how). Verifiable Itshould be verifiable by the clients or the customersfor whom the project is beingmade. Adaptable Itshould be adaptable in both sidesfrom the clients as well asfrom the developers. Maintainable SRS should be maintainable so in future changes can be made easily. Portable It should be portable as if we can use the contents of it for the same types of developments. Unambiguous There should not be any alternates of SRS that creates ambiguity. Traceable Each of the requirements should be clear and refer to the future development COHESION AND COUPLING Modularity is clearly a desirable property of any software development. In software development, modularity is decomposition of a program into smaller programs(or modules). A system is considered modularif it consists of multiple modulesso that each module can be implemented separately and debugged separately. Modularsystemprovides advantages like: Easy to understand the system. System maintenance is easy. Provide reusability. Requirement Analysis & Specification Software Engineering Modularity issuccessful because developers use prewritten code, which savesresources. Overall,modularity provides greatersoftware development manageability. Cohesion and coupling are two modularization criteria that are often used together. Mostresearchers and developers are agreed that for good software design neat decomposition is highly needed, and the primary characteristic of neat decomposition is'high cohesion and low coupling'. ▪ Cohesion: Cohesion is a measure of functionalstrength of a module. Cohesion keepsthe internal modulestogether, and represents the functionalstrength. Cohesion of a module represents how tightly bound the internal elements of a module are to one another. Coincidental cohesion It isthe lowest cohesion. Coincidental cohesion occurs when there are no meaningful relationships between the elements. Amodule issaid to have coincidental cohesion, ifit performs a set of tasks thatrelate to each other very loosely. It is also called random or unplanned cohesion. Logical cohesion A module issaid to be logically cohesive if there issome logicalrelationships between the elements ofmodule, and the elements perform functionsthatfall into same logical class. For example: the tasks of error handling, input and output of data. Temporal cohesion Temporal cohesion issame aslogical cohesion except that the elements are also related in time and they are executed together. Amodule isin temporal cohesion when amodule containsfunctionsthat must be executed in the same time span. Example: modules that perform activities like initialization, cleanup, and start-up, shut down are usually having temporal cohesion. Procedural cohesion A module has procedural cohesion when it contains elementsthat belong to common procedural unit. A module issaid to have procedural cohesion, if the set ofthe modules are all part of a procedure (algorithm) in which certain sequence ofsteps are carried out to achieve an objective. Requirement Analysis & Specification Software Engineering Example: the algorithm for decoding a message Communicational cohesion A module issaid to have communicational cohesion, if all functions ofthe module referto or update the same data structure, for example the set of functions defined on an array or a stack. Thesemodules may perform more than one function together. Sequential cohesion When the output of one element in a module formsthe input to another, we getsequential cohesion. Sequential cohesion does not provide any guideline how to combine these elementsinto modules. For example, in a TPS (transaction processing system), the get-input, validate-input,sort-inputfunctions are grouped into one module. Functional cohesion Functional cohesion isthe strongest cohesion. In it, all the elements of the module are related to perform a single task. All elements are achieving a single goal of a module. Functionslike: compute square root and sort the array are examples of these modules. ▪ Coupling: Coupling between two modulesis a measure ofthe degree ofinterdependence or interaction between these two modules. Coupling refersto the number of connections between 'calling' and a 'called' module. There must be at least one connection between them. It refersto the strengths of relationship between modulesin a system. It indicates how closely two modules interact and how they are interdependent. As modules becomemore interdependent, the coupling increases.And loose couplingminimize interdependency that is better for any system development. If two modulesinterchange large amount of data, then they are highly interdependent or we can say they are highlycoupled. High coupling between modules makesthe system difficult to understand and increase the development efforts. So low (OR loose) coupling isthe best. Data coupling Two modules are data coupled, ifthey communicate using an elementary data item that is passed as a parameter between these two. For example an int, a char, a float etc. It islowest coupling and best for the software development. Stamp coupling Two modules are stamp coupled, ifthey communicate using a composite data item such as a record in PASCAL or a structure in C. Control coupling Control coupling exists between two modules, if data from one module is used to direct the order ofinstructions execution in another module. An example of control coupling is a flag set in one module and tested in another module. Common coupling Two modules are common coupled, if they share data through some global data items. It meanstwo or more modules are communicating using common data. Content coupling It isthe highest coupling and creates more problemsin software development. Content coupling exists between two modules, if they share code, e.g. a branch fromone module into another module. It is also known as'pathological coupling'. ▪ Functional independence: A module having high cohesion and low coupling issaid to be functionally independent of othermodules. So, that a cohesivemodule performs a single task or function. A functionally independent module has minimal interaction with other modules. For good software design neat decomposition is highly needed, and the primary characteristic of neat decomposition is'high cohesion and low coupling'. Intra dependency (Cohesion) between modulesshould be high and inter dependency (Coupling)should be low. Need of functional independence: Functional independence is a good key to any software design process due to following reasons: 1. Error isolation: It reduces error propagation The reason behind thisis if a module isfunctionally independent, its degree of interaction with the other modulesisless. So, the error of one module can't affect another module. 2. Scope of reuse: Reuse of a module becomes possible. Because each module doessome well-defined and precise function, and the interaction ofthe module with the other modulesissimple and minimal.  Therefore, a cohesive module can be easily taken out and reused in a different program. 3. Understandability: Complexity ofthe design isreduced, because differentmodules can be understood in isolation as modules are more or lessindependent of each other. Difference between functional and non-functional requirements: Functional requirements Non-functional requirements These describe what the system should do. These describe how the system should behave. These describe features, functionality and usage of the system. They describe various quality factors, attributes which affect the system'sfunctionality. Describe the actions with which the work is concerned. Describe the experience of the user while doing the work. Characterized by verbs. Characterized by adjectives. Ex: business requirements, SRS etc. Ex: portability, quality, reliability, robustness, efficiency etc. Difference between Cohesion & Coupling: Cohesion Coupling Cohesion is the indication of the relationship within module. Coupling is the indication of the relationships between modules. Cohesion shows the module's relative functional strength. Coupling shows the relative interdependence among themodules. Cohesion is adegree (quality) towhich a component / module focuses on the single thing. Coupling is a degree to which a component / module is connected to the other modules. While designing you should go for high cohesion. i.e. a cohesive component/ module focus on a single task with little interaction with other modules of the system. While designing you should go for low coupling i.e., dependency between modulesshould be less. Cohesion is the kind of natural extension of data hiding for example, class having all members visible with a package having default visibility. Making private fields, private methods and nonpublic classes providesloose coupling. Cohesion isIntra - Module Concept. Coupling isInter -ModuleConcept.