{"id":122,"date":"2018-07-24T08:30:51","date_gmt":"2018-07-24T08:30:51","guid":{"rendered":"http:\/\/csp8.epgpbooks.inflibnet.ac.in\/?post_type=chapter&#038;p=122"},"modified":"2018-08-07T12:26:20","modified_gmt":"2018-08-07T12:26:20","slug":"requirements-engineering-iv","status":"publish","type":"chapter","link":"https:\/\/ebooks.inflibnet.ac.in\/csp8\/chapter\/requirements-engineering-iv\/","title":{"rendered":"Requirements Engineering IV"},"content":{"raw":"&nbsp;\r\n\r\n<strong>REQUIREMENTS ENGINEERING<\/strong>\r\n\r\n&nbsp;\r\n<p style=\"text-align: justify\"><span style=\"text-align: justify;font-size: 1em\">Requirement engineering plays a vital role towards the development of the system. It involves gathering requirements from the end-users and stakeholders and documentation of these requirements to facilitate the development of the system. The learning objective includes:<\/span><\/p>\r\n\r\n<div style=\"text-align: justify\">\r\n<ul>\r\n \t<li>To give a general introduction of requirements engineering process<\/li>\r\n \t<li>To describe the principal requirements engineering activities and their relationships.<\/li>\r\n \t<li>To introduce the concepts of user and system requirements.<\/li>\r\n \t<li>To describe functional and non functional requirements.<\/li>\r\n<\/ul>\r\n&nbsp;\r\n\r\n<strong>CHALLENGES IN REQUIREMENTS ELICITATION<\/strong>\r\n\r\n&nbsp;\r\n<p style=\"text-align: justify\">Requirement elicitation engages in gathering and collecting of requirements from the stakeholders. Some of the challenges that are encountered during elicitation of requirements are three endemic syndromes that are as follows:<\/p>\r\n\r\n<ul>\r\n \t<li>Yes-but syndrome: When the stakeholders are not sure about the specifications, or have vague idea about the system, they tend to provide hazy requirements and are inconsistent about their specification.<\/li>\r\n \t<li>Undiscovered ruin syndrome: The search for requirements is like a search for undiscovered ruins, the more you find the more you know remain.<\/li>\r\n \t<li>User and the developer syndrome: Communication gap between the user and the developer.<\/li>\r\n<\/ul>\r\n&nbsp;\r\n\r\n<strong>TYPES OF DATA<\/strong>\r\n\r\n&nbsp;\r\n\r\nData could be of two different types of classes:\r\n<ul>\r\n \t<li>Qualitative (descriptive information) and quantitative data (numerical information).<\/li>\r\n \t<li>Structured (high degree of organization such as relational database) and unstructured data (Information that is difficult to organize using traditional mechanisms).<\/li>\r\n<\/ul>\r\n&nbsp;\r\n\r\n<strong>METHODS <\/strong><strong>FOR COLLECTING DATA<\/strong>\r\n\r\n&nbsp;\r\n<p style=\"text-align: justify\"><span style=\"font-size: 1em;text-align: initial\">Data collection involves elicitation and gathering of information from stakeholders and end users. Data collection is done by various methods such as:<\/span><\/p>\r\n\r\n<\/div>\r\n<div style=\"text-align: justify\">\r\n<ul>\r\n \t<li><strong>Interview: <\/strong>Interviews are conducted with different level of stakeholders to solicit their views, suggestions and opinions on how the system has to be developed. The views and suggestion are collected from the stakeholders by conducting interviews, but it has its own pros and cons.<\/li>\r\n<\/ul>\r\n&nbsp;\r\n\r\n<strong style=\"text-align: initial;font-size: 1em\">*\u00a0 Pros<\/strong>\r\n\r\n<\/div>\r\n<ul>\r\n \t<li>Rich collection of information<\/li>\r\n \t<li>Uncovers opinions, feelings, goals, as well as hard facts.<\/li>\r\n \t<li>Can review in detail, and adapt follow-up questions to what the person tells you.<\/li>\r\n<\/ul>\r\n&nbsp;\r\n\r\n<strong>*\u00a0 Cons<\/strong>\r\n<ul>\r\n \t<li>Large amount of qualitative data can be hard to analyze<\/li>\r\n \t<li>Not as many people from various parts of the company are interviewed, because of cost there exists high possibility for bias.<\/li>\r\n \t<li>Usually many follow ups are required for clarification.<\/li>\r\n \t<li>Interviewing is a difficult skill to master.<\/li>\r\n<\/ul>\r\n<ul>\r\n \t<li><strong>Questionnaires \u2013 <\/strong>Preparation of questionnaires and gathering honest response from the members leads to collection of data.<\/li>\r\n \t<li><strong>Background reading \u2013 <\/strong>Background study and comprehension of the system leads to collection of data<\/li>\r\n \t<li><strong>Introspection \u2013 <\/strong>The analyst \u201cimagines\u201d what kind of system is required for doing the required job, or by using available equipment collects data<\/li>\r\n \t<li><strong>Social analysis \u2013 <\/strong>collects data through observation.<\/li>\r\n \t<li><strong>Brainstorming - <\/strong>A group technique for generating new, productive ideas and promoting creative thinking for finding the solution to a specific issue<\/li>\r\n \t<li><strong>Story boarding - <\/strong>Story board is a logical and conceptual description of system functionality for a specific scenario, including the interaction required between the users and the system.<\/li>\r\n \t<li><strong>Prototyping \u2013 <\/strong>Data is collected with the help of prototypes.<\/li>\r\n \t<li><strong style=\"font-size: 1em;text-align: initial\">Role playing \u2013 <\/strong><span style=\"font-size: 1em;text-align: initial\">It allows the members to take up different roles to express their views and opinions.<\/span><\/li>\r\n \t<li><strong style=\"text-align: initial;font-size: 1em\">Requirement \u00a0reuse \u00a0\u2013 \u00a0<\/strong><span style=\"text-align: initial;font-size: 1em\">Requirements \u00a0are \u00a0reused \u00a0when \u00a0similar \u00a0types \u00a0of \u00a0systems \u00a0are developed.<\/span><\/li>\r\n<\/ul>\r\n<div style=\"text-align: justify\">\r\n\r\n&nbsp;\r\n\r\n<strong>METHODS FOR REQUIREMENT SPECIFICATION<\/strong>\r\n\r\n&nbsp;\r\n<p style=\"text-align: justify\">Requirement specification is appropriate when description in language is too complex and when they can\u2019t afford to have requirement misinterpretation. Some methods for requirement specification are as follows:<\/p>\r\n\r\n<ul>\r\n \t<li>Pseudo code<\/li>\r\n \t<li>Finite state machines<\/li>\r\n \t<li>Decision tree<\/li>\r\n \t<li>Object oriented modeling<\/li>\r\n \t<li>Entity relationship models and many others.<\/li>\r\n<\/ul>\r\n&nbsp;\r\n\r\n<strong>Pseudo code<\/strong>\r\n\r\n&nbsp;\r\n<p style=\"text-align: justify\">Pseudo code attempts to combine the informality of natural language with the strict syntax and control structures of a programming language. It comprises of imperative statements, a limited set of 40-50 \u201caction oriented\u201d verbs from which the sentences are constructed. The decisions are majorly represented with formal IF-ELSE-ENDIF structure. The iterative activities are represented with loops like DO, WHILE or FOR. Example for a pseudo code is given below:<\/p>\r\n\r\n<\/div>\r\n<img class=\"aligncenter size-full wp-image-125\" src=\"http:\/\/csp8.epgpbooks.inflibnet.ac.in\/wp-content\/uploads\/sites\/53\/2018\/07\/Untitled-10.png\" alt=\"\" width=\"457\" height=\"444\" \/>\r\n<div style=\"text-align: justify\">\r\n\r\n&nbsp;\r\n\r\n<strong>Finite State Machine<\/strong>\r\n\r\n&nbsp;\r\n<p style=\"text-align: justify\"><span style=\"font-size: 1em;text-align: initial\">Finite state machine can be in only one of a given number of \u201cstates\u201d at any specific time. In response to an input, such as data entry from the user, or an input from an external device the machine changes its state and then generates an output or carries out an action. Both the output and the next state can be determined exclusively on the basis of understanding the current state and the event that caused transition. In that way the system\u2019s behavior can be said to be deterministic.\u00a0 The following example shows the finite states while driving a car.<\/span><\/p>\r\n\r\n<\/div>\r\n<div style=\"text-align: justify\">\r\n\r\n<img class=\"aligncenter size-full wp-image-126\" src=\"http:\/\/csp8.epgpbooks.inflibnet.ac.in\/wp-content\/uploads\/sites\/53\/2018\/07\/Untitled-11.png\" alt=\"\" width=\"595\" height=\"389\" \/>\r\n\r\n<strong><span style=\"text-align: justify;font-size: 1em\">Decision Trees<\/span><\/strong>\r\n\r\n&nbsp;\r\n<p style=\"text-align: justify\">Decision trees are employed when dealing requirements with combination of inputs, different combination of input leads to different behaviors or outputs. The combination of IF- THEN-ELSE clauses becomes quickly twisted, when the conditions are nested.<\/p>\r\n&nbsp;\r\n\r\n<strong>Object Orient Modeling<\/strong>\r\n\r\n&nbsp;\r\n<p style=\"text-align: justify\">If the requirements involve the description of the structure and relationship among entities within the system, it\u2019s often beneficial to use object oriented models to fully describe the system. Examples for this modeling involve generation of class or sequential diagrams.<\/p>\r\n\r\n<\/div>\r\n<img class=\"aligncenter size-full wp-image-127\" src=\"http:\/\/csp8.epgpbooks.inflibnet.ac.in\/wp-content\/uploads\/sites\/53\/2018\/07\/Untitled-12.png\" alt=\"\" width=\"795\" height=\"300\" \/>\r\n<div style=\"text-align: justify\">\r\n\r\n&nbsp;\r\n\r\n<strong>Entity relationship models<\/strong>\r\n\r\n&nbsp;\r\n<p style=\"text-align: justify\"><span style=\"font-size: 1em;text-align: initial\">Entity relationship model (ER model) is a data model for describing a database in an abstract way. ER model provides a high level \u201carchitectural\u201d view of the data. The given example provides the entity relationship model for an employee working in a department.<\/span><\/p>\r\n\r\n<\/div>\r\n<div style=\"text-align: justify\">\r\n\r\n<img class=\"aligncenter wp-image-128\" src=\"http:\/\/csp8.epgpbooks.inflibnet.ac.in\/wp-content\/uploads\/sites\/53\/2018\/07\/Untitled-13.png\" alt=\"\" width=\"665\" height=\"278\" \/>\r\n\r\n<strong>QUALITY MEASURES FOR WELL FORMED REQUIREMENTS<\/strong>\r\n\r\n&nbsp;\r\n\r\nThe quality of a well formed requirement is determined using the following measures:\r\n<ul>\r\n \t<li>Correctness \u2013 If every requirement stated represents something required of the system to build<\/li>\r\n \t<li>Un-ambiguous \u2013 The requirements are subjected to only one interpretation as the requirements can be interpreted differently by the developers, users and other stakeholders. Requirements must be very clear and must be interpreted singularly.<\/li>\r\n \t<li>Complete - All significant requirements of concern to the user, including requirements associated with the functionality, performance, design constraints, attributes or external interfaces.\u00a0 It projects the functionalities and features that system should provide.<\/li>\r\n \t<li>Consistent \u2013 No subset of individual requirements described within are in conflict with another requirements.<\/li>\r\n \t<li>Verifiable \u2013 The requirements specified must be testable, therefore appropriate test procedures are carried out for verification.<\/li>\r\n \t<li>Modifiable \u2013 Changes to the requirements can be made easily, completely and consistently, while retaining the existing structure and style of the set. It provides a provision for modification without changing the structure and style of the system.<\/li>\r\n \t<li>Traceable - Origin of each of its component requirements must be clear to trace back if there is any shortcomings in the system. The system should try to provide mechanism that makes it feasible to refer to the requirement that causes inadequacy in the development of the system.<\/li>\r\n \t<li>Understandable \u2013 The user and the developer community must be able to fully understand the individual requirements and the aggregate functionality implied by the set.<\/li>\r\n<\/ul>\r\n<\/div>\r\n<div style=\"text-align: justify\">\r\n\r\n&nbsp;\r\n\r\n<strong>REQUIREMENTS VALIDATION \u2013 TRACEABILITY<\/strong>\r\n\r\n&nbsp;\r\n\r\nIEEE in 1994 provided the following compound definition of traceability:\r\n<ul>\r\n \t<li>Ability to describe and follow the life of a requirement, in both forward and backward direction.<\/li>\r\n \t<li>Traceability importance increases where the rate of change is high.<\/li>\r\n \t<li>Some requirements are volatile.<\/li>\r\n<\/ul>\r\n&nbsp;\r\n\r\n<strong>C<\/strong><strong>lassification of Requirement Traceability<\/strong>\r\n\r\n&nbsp;\r\n<p style=\"text-align: justify\">Requirement traceability can be classified into two types: Forward traceability and backward traceability.<\/p>\r\n\r\n<ul>\r\n \t<li>Forward traceability \u2013 Each input of the phase must be traced to the output of that phase.<\/li>\r\n \t<li>Backward traceability \u2013 Each output of a phase must be traceable to an input of that phase.<\/li>\r\n<\/ul>\r\n&nbsp;\r\n\r\nOutputs that cannot be traced to inputs are extra, unless it is acknowledged that input themselves were incomplete.\r\n\r\n&nbsp;\r\n<p style=\"text-align: justify\">An example of the traceability matrix is given as follows, where the list of features and their needs are depicted in a matrix of n * m. The stakeholder\u2019s needs and product features are depicted and with help of product features, one can trace back the needs of the stakeholders. The matrix features and use cases are also given, where the product feature can be traced from the use cases.<\/p>\r\n&nbsp;\r\n\r\nTraceability matrix for tracing product features\r\n\r\n<\/div>\r\n<div style=\"text-align: justify\">\r\n\r\n<img class=\"aligncenter size-full wp-image-129\" src=\"http:\/\/csp8.epgpbooks.inflibnet.ac.in\/wp-content\/uploads\/sites\/53\/2018\/07\/Untitled-14.png\" alt=\"\" width=\"1044\" height=\"441\" \/>\r\n\r\n<strong>REQUIREMENT REVIEWS<\/strong>\r\n\r\n&nbsp;\r\n<p style=\"text-align: justify\">Requirement review involves a group of people to conduct requirement analysis, determine the problems and issues encountered, conduct discussion about the problem and agree on the actions to address these problems. It is a formal meeting headed by a leader. Reviews are conducted not only to uncover errors but also to check conformance of standards.<\/p>\r\n&nbsp;\r\n\r\n<strong>Requirement Review Process<\/strong>\r\n\r\n&nbsp;\r\n\r\n<span style=\"font-size: 1em;text-align: initial\">A requirement review process goes through the following phases as shown in the below\u00a0figure.<\/span>\r\n\r\n<\/div>\r\n<img class=\"aligncenter size-full wp-image-130\" src=\"http:\/\/csp8.epgpbooks.inflibnet.ac.in\/wp-content\/uploads\/sites\/53\/2018\/07\/Untitled-15.png\" alt=\"\" width=\"647\" height=\"349\" \/>\r\n<p style=\"text-align: justify\">The members plan the review to be conducted and distribute documents that contains the goals and agenda of the review. The members prepare for the review and the review meeting is conducted. The members express their views and suggestions to uncover errors and faults in the specification and development cycle. After uncovering and prioritizing the errors and shortcomings, necessary follow up actions are discussed to overcome the inadequacies in the system. The review session is documented and the specification documents are revised. The process bridges the gap between the stakeholders and the developers and improves the standard and efficiency of the system.<\/p>\r\n&nbsp;\r\n\r\n&nbsp;\r\n\r\n<strong>Web Links<\/strong>\r\n<ul>\r\n \t<li>https:\/\/en.wikipedia.org\/wiki\/Requirements_engineering<\/li>\r\n \t<li>http:\/\/www.tutorialspoint.com\/software_engineering\/software_requirements.htm<\/li>\r\n \t<li>http:\/\/www.cs.toronto.edu\/~sme\/papers\/2004\/FoRE-chapter01-v7.pdf<\/li>\r\n \t<li>http:\/\/resources .sei.cmu.edu\/asset_files\/TechnicalReport\/2005_005_001_14594.pdf<\/li>\r\n<\/ul>\r\n&nbsp;\r\n\r\n<strong>Supporting &amp; Reference Materials<\/strong>\r\n<ul>\r\n \t<li>Roger S. Pressman, \u201cSoftware Engineering: A Practitioner\u2019s Approach\u201d, Fifth Edition, McGraw Hill, 2001.<\/li>\r\n \t<li>Pankaj Jalote, \u201cAn Integrated Approach to Software Engineering\u201d, Second Edition, Springer Verlag, 1997.<\/li>\r\n \t<li>Ian Sommerville, \u201cSoftware Engineering\u201d, Sixth Edition, Addison Wesley, 2000.<\/li>\r\n<\/ul>","rendered":"<p>&nbsp;<\/p>\n<p><strong>REQUIREMENTS ENGINEERING<\/strong><\/p>\n<p>&nbsp;<\/p>\n<p style=\"text-align: justify\"><span style=\"text-align: justify;font-size: 1em\">Requirement engineering plays a vital role towards the development of the system. It involves gathering requirements from the end-users and stakeholders and documentation of these requirements to facilitate the development of the system. The learning objective includes:<\/span><\/p>\n<div style=\"text-align: justify\">\n<ul>\n<li>To give a general introduction of requirements engineering process<\/li>\n<li>To describe the principal requirements engineering activities and their relationships.<\/li>\n<li>To introduce the concepts of user and system requirements.<\/li>\n<li>To describe functional and non functional requirements.<\/li>\n<\/ul>\n<p>&nbsp;<\/p>\n<p><strong>CHALLENGES IN REQUIREMENTS ELICITATION<\/strong><\/p>\n<p>&nbsp;<\/p>\n<p style=\"text-align: justify\">Requirement elicitation engages in gathering and collecting of requirements from the stakeholders. Some of the challenges that are encountered during elicitation of requirements are three endemic syndromes that are as follows:<\/p>\n<ul>\n<li>Yes-but syndrome: When the stakeholders are not sure about the specifications, or have vague idea about the system, they tend to provide hazy requirements and are inconsistent about their specification.<\/li>\n<li>Undiscovered ruin syndrome: The search for requirements is like a search for undiscovered ruins, the more you find the more you know remain.<\/li>\n<li>User and the developer syndrome: Communication gap between the user and the developer.<\/li>\n<\/ul>\n<p>&nbsp;<\/p>\n<p><strong>TYPES OF DATA<\/strong><\/p>\n<p>&nbsp;<\/p>\n<p>Data could be of two different types of classes:<\/p>\n<ul>\n<li>Qualitative (descriptive information) and quantitative data (numerical information).<\/li>\n<li>Structured (high degree of organization such as relational database) and unstructured data (Information that is difficult to organize using traditional mechanisms).<\/li>\n<\/ul>\n<p>&nbsp;<\/p>\n<p><strong>METHODS <\/strong><strong>FOR COLLECTING DATA<\/strong><\/p>\n<p>&nbsp;<\/p>\n<p style=\"text-align: justify\"><span style=\"font-size: 1em;text-align: initial\">Data collection involves elicitation and gathering of information from stakeholders and end users. Data collection is done by various methods such as:<\/span><\/p>\n<\/div>\n<div style=\"text-align: justify\">\n<ul>\n<li><strong>Interview: <\/strong>Interviews are conducted with different level of stakeholders to solicit their views, suggestions and opinions on how the system has to be developed. The views and suggestion are collected from the stakeholders by conducting interviews, but it has its own pros and cons.<\/li>\n<\/ul>\n<p>&nbsp;<\/p>\n<p><strong style=\"text-align: initial;font-size: 1em\">*\u00a0 Pros<\/strong><\/p>\n<\/div>\n<ul>\n<li>Rich collection of information<\/li>\n<li>Uncovers opinions, feelings, goals, as well as hard facts.<\/li>\n<li>Can review in detail, and adapt follow-up questions to what the person tells you.<\/li>\n<\/ul>\n<p>&nbsp;<\/p>\n<p><strong>*\u00a0 Cons<\/strong><\/p>\n<ul>\n<li>Large amount of qualitative data can be hard to analyze<\/li>\n<li>Not as many people from various parts of the company are interviewed, because of cost there exists high possibility for bias.<\/li>\n<li>Usually many follow ups are required for clarification.<\/li>\n<li>Interviewing is a difficult skill to master.<\/li>\n<\/ul>\n<ul>\n<li><strong>Questionnaires \u2013 <\/strong>Preparation of questionnaires and gathering honest response from the members leads to collection of data.<\/li>\n<li><strong>Background reading \u2013 <\/strong>Background study and comprehension of the system leads to collection of data<\/li>\n<li><strong>Introspection \u2013 <\/strong>The analyst \u201cimagines\u201d what kind of system is required for doing the required job, or by using available equipment collects data<\/li>\n<li><strong>Social analysis \u2013 <\/strong>collects data through observation.<\/li>\n<li><strong>Brainstorming &#8211; <\/strong>A group technique for generating new, productive ideas and promoting creative thinking for finding the solution to a specific issue<\/li>\n<li><strong>Story boarding &#8211; <\/strong>Story board is a logical and conceptual description of system functionality for a specific scenario, including the interaction required between the users and the system.<\/li>\n<li><strong>Prototyping \u2013 <\/strong>Data is collected with the help of prototypes.<\/li>\n<li><strong style=\"font-size: 1em;text-align: initial\">Role playing \u2013 <\/strong><span style=\"font-size: 1em;text-align: initial\">It allows the members to take up different roles to express their views and opinions.<\/span><\/li>\n<li><strong style=\"text-align: initial;font-size: 1em\">Requirement \u00a0reuse \u00a0\u2013 \u00a0<\/strong><span style=\"text-align: initial;font-size: 1em\">Requirements \u00a0are \u00a0reused \u00a0when \u00a0similar \u00a0types \u00a0of \u00a0systems \u00a0are developed.<\/span><\/li>\n<\/ul>\n<div style=\"text-align: justify\">\n<p>&nbsp;<\/p>\n<p><strong>METHODS FOR REQUIREMENT SPECIFICATION<\/strong><\/p>\n<p>&nbsp;<\/p>\n<p style=\"text-align: justify\">Requirement specification is appropriate when description in language is too complex and when they can\u2019t afford to have requirement misinterpretation. Some methods for requirement specification are as follows:<\/p>\n<ul>\n<li>Pseudo code<\/li>\n<li>Finite state machines<\/li>\n<li>Decision tree<\/li>\n<li>Object oriented modeling<\/li>\n<li>Entity relationship models and many others.<\/li>\n<\/ul>\n<p>&nbsp;<\/p>\n<p><strong>Pseudo code<\/strong><\/p>\n<p>&nbsp;<\/p>\n<p style=\"text-align: justify\">Pseudo code attempts to combine the informality of natural language with the strict syntax and control structures of a programming language. It comprises of imperative statements, a limited set of 40-50 \u201caction oriented\u201d verbs from which the sentences are constructed. The decisions are majorly represented with formal IF-ELSE-ENDIF structure. The iterative activities are represented with loops like DO, WHILE or FOR. Example for a pseudo code is given below:<\/p>\n<\/div>\n<p><img loading=\"lazy\" decoding=\"async\" class=\"aligncenter size-full wp-image-125\" src=\"http:\/\/csp8.epgpbooks.inflibnet.ac.in\/wp-content\/uploads\/sites\/53\/2018\/07\/Untitled-10.png\" alt=\"\" width=\"457\" height=\"444\" srcset=\"https:\/\/ebooks.inflibnet.ac.in\/csp8\/wp-content\/uploads\/sites\/53\/2018\/07\/Untitled-10.png 457w, https:\/\/ebooks.inflibnet.ac.in\/csp8\/wp-content\/uploads\/sites\/53\/2018\/07\/Untitled-10-300x291.png 300w, https:\/\/ebooks.inflibnet.ac.in\/csp8\/wp-content\/uploads\/sites\/53\/2018\/07\/Untitled-10-65x63.png 65w, https:\/\/ebooks.inflibnet.ac.in\/csp8\/wp-content\/uploads\/sites\/53\/2018\/07\/Untitled-10-225x219.png 225w, https:\/\/ebooks.inflibnet.ac.in\/csp8\/wp-content\/uploads\/sites\/53\/2018\/07\/Untitled-10-350x340.png 350w\" sizes=\"auto, (max-width: 457px) 100vw, 457px\" \/><\/p>\n<div style=\"text-align: justify\">\n<p>&nbsp;<\/p>\n<p><strong>Finite State Machine<\/strong><\/p>\n<p>&nbsp;<\/p>\n<p style=\"text-align: justify\"><span style=\"font-size: 1em;text-align: initial\">Finite state machine can be in only one of a given number of \u201cstates\u201d at any specific time. In response to an input, such as data entry from the user, or an input from an external device the machine changes its state and then generates an output or carries out an action. Both the output and the next state can be determined exclusively on the basis of understanding the current state and the event that caused transition. In that way the system\u2019s behavior can be said to be deterministic.\u00a0 The following example shows the finite states while driving a car.<\/span><\/p>\n<\/div>\n<div style=\"text-align: justify\">\n<p><img loading=\"lazy\" decoding=\"async\" class=\"aligncenter size-full wp-image-126\" src=\"http:\/\/csp8.epgpbooks.inflibnet.ac.in\/wp-content\/uploads\/sites\/53\/2018\/07\/Untitled-11.png\" alt=\"\" width=\"595\" height=\"389\" srcset=\"https:\/\/ebooks.inflibnet.ac.in\/csp8\/wp-content\/uploads\/sites\/53\/2018\/07\/Untitled-11.png 595w, https:\/\/ebooks.inflibnet.ac.in\/csp8\/wp-content\/uploads\/sites\/53\/2018\/07\/Untitled-11-300x196.png 300w, https:\/\/ebooks.inflibnet.ac.in\/csp8\/wp-content\/uploads\/sites\/53\/2018\/07\/Untitled-11-65x42.png 65w, https:\/\/ebooks.inflibnet.ac.in\/csp8\/wp-content\/uploads\/sites\/53\/2018\/07\/Untitled-11-225x147.png 225w, https:\/\/ebooks.inflibnet.ac.in\/csp8\/wp-content\/uploads\/sites\/53\/2018\/07\/Untitled-11-350x229.png 350w\" sizes=\"auto, (max-width: 595px) 100vw, 595px\" \/><\/p>\n<p><strong><span style=\"text-align: justify;font-size: 1em\">Decision Trees<\/span><\/strong><\/p>\n<p>&nbsp;<\/p>\n<p style=\"text-align: justify\">Decision trees are employed when dealing requirements with combination of inputs, different combination of input leads to different behaviors or outputs. The combination of IF- THEN-ELSE clauses becomes quickly twisted, when the conditions are nested.<\/p>\n<p>&nbsp;<\/p>\n<p><strong>Object Orient Modeling<\/strong><\/p>\n<p>&nbsp;<\/p>\n<p style=\"text-align: justify\">If the requirements involve the description of the structure and relationship among entities within the system, it\u2019s often beneficial to use object oriented models to fully describe the system. Examples for this modeling involve generation of class or sequential diagrams.<\/p>\n<\/div>\n<p><img loading=\"lazy\" decoding=\"async\" class=\"aligncenter size-full wp-image-127\" src=\"http:\/\/csp8.epgpbooks.inflibnet.ac.in\/wp-content\/uploads\/sites\/53\/2018\/07\/Untitled-12.png\" alt=\"\" width=\"795\" height=\"300\" srcset=\"https:\/\/ebooks.inflibnet.ac.in\/csp8\/wp-content\/uploads\/sites\/53\/2018\/07\/Untitled-12.png 795w, https:\/\/ebooks.inflibnet.ac.in\/csp8\/wp-content\/uploads\/sites\/53\/2018\/07\/Untitled-12-300x113.png 300w, https:\/\/ebooks.inflibnet.ac.in\/csp8\/wp-content\/uploads\/sites\/53\/2018\/07\/Untitled-12-768x290.png 768w, https:\/\/ebooks.inflibnet.ac.in\/csp8\/wp-content\/uploads\/sites\/53\/2018\/07\/Untitled-12-65x25.png 65w, https:\/\/ebooks.inflibnet.ac.in\/csp8\/wp-content\/uploads\/sites\/53\/2018\/07\/Untitled-12-225x85.png 225w, https:\/\/ebooks.inflibnet.ac.in\/csp8\/wp-content\/uploads\/sites\/53\/2018\/07\/Untitled-12-350x132.png 350w\" sizes=\"auto, (max-width: 795px) 100vw, 795px\" \/><\/p>\n<div style=\"text-align: justify\">\n<p>&nbsp;<\/p>\n<p><strong>Entity relationship models<\/strong><\/p>\n<p>&nbsp;<\/p>\n<p style=\"text-align: justify\"><span style=\"font-size: 1em;text-align: initial\">Entity relationship model (ER model) is a data model for describing a database in an abstract way. ER model provides a high level \u201carchitectural\u201d view of the data. The given example provides the entity relationship model for an employee working in a department.<\/span><\/p>\n<\/div>\n<div style=\"text-align: justify\">\n<p><img loading=\"lazy\" decoding=\"async\" class=\"aligncenter wp-image-128\" src=\"http:\/\/csp8.epgpbooks.inflibnet.ac.in\/wp-content\/uploads\/sites\/53\/2018\/07\/Untitled-13.png\" alt=\"\" width=\"665\" height=\"278\" srcset=\"https:\/\/ebooks.inflibnet.ac.in\/csp8\/wp-content\/uploads\/sites\/53\/2018\/07\/Untitled-13.png 756w, https:\/\/ebooks.inflibnet.ac.in\/csp8\/wp-content\/uploads\/sites\/53\/2018\/07\/Untitled-13-300x125.png 300w, https:\/\/ebooks.inflibnet.ac.in\/csp8\/wp-content\/uploads\/sites\/53\/2018\/07\/Untitled-13-65x27.png 65w, https:\/\/ebooks.inflibnet.ac.in\/csp8\/wp-content\/uploads\/sites\/53\/2018\/07\/Untitled-13-225x94.png 225w, https:\/\/ebooks.inflibnet.ac.in\/csp8\/wp-content\/uploads\/sites\/53\/2018\/07\/Untitled-13-350x146.png 350w\" sizes=\"auto, (max-width: 665px) 100vw, 665px\" \/><\/p>\n<p><strong>QUALITY MEASURES FOR WELL FORMED REQUIREMENTS<\/strong><\/p>\n<p>&nbsp;<\/p>\n<p>The quality of a well formed requirement is determined using the following measures:<\/p>\n<ul>\n<li>Correctness \u2013 If every requirement stated represents something required of the system to build<\/li>\n<li>Un-ambiguous \u2013 The requirements are subjected to only one interpretation as the requirements can be interpreted differently by the developers, users and other stakeholders. Requirements must be very clear and must be interpreted singularly.<\/li>\n<li>Complete &#8211; All significant requirements of concern to the user, including requirements associated with the functionality, performance, design constraints, attributes or external interfaces.\u00a0 It projects the functionalities and features that system should provide.<\/li>\n<li>Consistent \u2013 No subset of individual requirements described within are in conflict with another requirements.<\/li>\n<li>Verifiable \u2013 The requirements specified must be testable, therefore appropriate test procedures are carried out for verification.<\/li>\n<li>Modifiable \u2013 Changes to the requirements can be made easily, completely and consistently, while retaining the existing structure and style of the set. It provides a provision for modification without changing the structure and style of the system.<\/li>\n<li>Traceable &#8211; Origin of each of its component requirements must be clear to trace back if there is any shortcomings in the system. The system should try to provide mechanism that makes it feasible to refer to the requirement that causes inadequacy in the development of the system.<\/li>\n<li>Understandable \u2013 The user and the developer community must be able to fully understand the individual requirements and the aggregate functionality implied by the set.<\/li>\n<\/ul>\n<\/div>\n<div style=\"text-align: justify\">\n<p>&nbsp;<\/p>\n<p><strong>REQUIREMENTS VALIDATION \u2013 TRACEABILITY<\/strong><\/p>\n<p>&nbsp;<\/p>\n<p>IEEE in 1994 provided the following compound definition of traceability:<\/p>\n<ul>\n<li>Ability to describe and follow the life of a requirement, in both forward and backward direction.<\/li>\n<li>Traceability importance increases where the rate of change is high.<\/li>\n<li>Some requirements are volatile.<\/li>\n<\/ul>\n<p>&nbsp;<\/p>\n<p><strong>C<\/strong><strong>lassification of Requirement Traceability<\/strong><\/p>\n<p>&nbsp;<\/p>\n<p style=\"text-align: justify\">Requirement traceability can be classified into two types: Forward traceability and backward traceability.<\/p>\n<ul>\n<li>Forward traceability \u2013 Each input of the phase must be traced to the output of that phase.<\/li>\n<li>Backward traceability \u2013 Each output of a phase must be traceable to an input of that phase.<\/li>\n<\/ul>\n<p>&nbsp;<\/p>\n<p>Outputs that cannot be traced to inputs are extra, unless it is acknowledged that input themselves were incomplete.<\/p>\n<p>&nbsp;<\/p>\n<p style=\"text-align: justify\">An example of the traceability matrix is given as follows, where the list of features and their needs are depicted in a matrix of n * m. The stakeholder\u2019s needs and product features are depicted and with help of product features, one can trace back the needs of the stakeholders. The matrix features and use cases are also given, where the product feature can be traced from the use cases.<\/p>\n<p>&nbsp;<\/p>\n<p>Traceability matrix for tracing product features<\/p>\n<\/div>\n<div style=\"text-align: justify\">\n<p><img loading=\"lazy\" decoding=\"async\" class=\"aligncenter size-full wp-image-129\" src=\"http:\/\/csp8.epgpbooks.inflibnet.ac.in\/wp-content\/uploads\/sites\/53\/2018\/07\/Untitled-14.png\" alt=\"\" width=\"1044\" height=\"441\" srcset=\"https:\/\/ebooks.inflibnet.ac.in\/csp8\/wp-content\/uploads\/sites\/53\/2018\/07\/Untitled-14.png 1044w, https:\/\/ebooks.inflibnet.ac.in\/csp8\/wp-content\/uploads\/sites\/53\/2018\/07\/Untitled-14-300x127.png 300w, https:\/\/ebooks.inflibnet.ac.in\/csp8\/wp-content\/uploads\/sites\/53\/2018\/07\/Untitled-14-768x324.png 768w, https:\/\/ebooks.inflibnet.ac.in\/csp8\/wp-content\/uploads\/sites\/53\/2018\/07\/Untitled-14-1024x433.png 1024w, https:\/\/ebooks.inflibnet.ac.in\/csp8\/wp-content\/uploads\/sites\/53\/2018\/07\/Untitled-14-65x27.png 65w, https:\/\/ebooks.inflibnet.ac.in\/csp8\/wp-content\/uploads\/sites\/53\/2018\/07\/Untitled-14-225x95.png 225w, https:\/\/ebooks.inflibnet.ac.in\/csp8\/wp-content\/uploads\/sites\/53\/2018\/07\/Untitled-14-350x148.png 350w\" sizes=\"auto, (max-width: 1044px) 100vw, 1044px\" \/><\/p>\n<p><strong>REQUIREMENT REVIEWS<\/strong><\/p>\n<p>&nbsp;<\/p>\n<p style=\"text-align: justify\">Requirement review involves a group of people to conduct requirement analysis, determine the problems and issues encountered, conduct discussion about the problem and agree on the actions to address these problems. It is a formal meeting headed by a leader. Reviews are conducted not only to uncover errors but also to check conformance of standards.<\/p>\n<p>&nbsp;<\/p>\n<p><strong>Requirement Review Process<\/strong><\/p>\n<p>&nbsp;<\/p>\n<p><span style=\"font-size: 1em;text-align: initial\">A requirement review process goes through the following phases as shown in the below\u00a0figure.<\/span><\/p>\n<\/div>\n<p><img loading=\"lazy\" decoding=\"async\" class=\"aligncenter size-full wp-image-130\" src=\"http:\/\/csp8.epgpbooks.inflibnet.ac.in\/wp-content\/uploads\/sites\/53\/2018\/07\/Untitled-15.png\" alt=\"\" width=\"647\" height=\"349\" srcset=\"https:\/\/ebooks.inflibnet.ac.in\/csp8\/wp-content\/uploads\/sites\/53\/2018\/07\/Untitled-15.png 647w, https:\/\/ebooks.inflibnet.ac.in\/csp8\/wp-content\/uploads\/sites\/53\/2018\/07\/Untitled-15-300x162.png 300w, https:\/\/ebooks.inflibnet.ac.in\/csp8\/wp-content\/uploads\/sites\/53\/2018\/07\/Untitled-15-65x35.png 65w, https:\/\/ebooks.inflibnet.ac.in\/csp8\/wp-content\/uploads\/sites\/53\/2018\/07\/Untitled-15-225x121.png 225w, https:\/\/ebooks.inflibnet.ac.in\/csp8\/wp-content\/uploads\/sites\/53\/2018\/07\/Untitled-15-350x189.png 350w\" sizes=\"auto, (max-width: 647px) 100vw, 647px\" \/><\/p>\n<p style=\"text-align: justify\">The members plan the review to be conducted and distribute documents that contains the goals and agenda of the review. The members prepare for the review and the review meeting is conducted. The members express their views and suggestions to uncover errors and faults in the specification and development cycle. After uncovering and prioritizing the errors and shortcomings, necessary follow up actions are discussed to overcome the inadequacies in the system. The review session is documented and the specification documents are revised. The process bridges the gap between the stakeholders and the developers and improves the standard and efficiency of the system.<\/p>\n<p>&nbsp;<\/p>\n<p>&nbsp;<\/p>\n<p><strong>Web Links<\/strong><\/p>\n<ul>\n<li>https:\/\/en.wikipedia.org\/wiki\/Requirements_engineering<\/li>\n<li>http:\/\/www.tutorialspoint.com\/software_engineering\/software_requirements.htm<\/li>\n<li>http:\/\/www.cs.toronto.edu\/~sme\/papers\/2004\/FoRE-chapter01-v7.pdf<\/li>\n<li>http:\/\/resources .sei.cmu.edu\/asset_files\/TechnicalReport\/2005_005_001_14594.pdf<\/li>\n<\/ul>\n<p>&nbsp;<\/p>\n<p><strong>Supporting &amp; Reference Materials<\/strong><\/p>\n<ul>\n<li>Roger S. Pressman, \u201cSoftware Engineering: A Practitioner\u2019s Approach\u201d, Fifth Edition, McGraw Hill, 2001.<\/li>\n<li>Pankaj Jalote, \u201cAn Integrated Approach to Software Engineering\u201d, Second Edition, Springer Verlag, 1997.<\/li>\n<li>Ian Sommerville, \u201cSoftware Engineering\u201d, Sixth Edition, Addison Wesley, 2000.<\/li>\n<\/ul>\n","protected":false},"author":4,"menu_order":13,"template":"","meta":{"pb_show_title":"on","pb_short_title":"","pb_subtitle":"","pb_authors":["dr-r-baskaran"],"pb_section_license":""},"chapter-type":[],"contributor":[58],"license":[],"class_list":["post-122","chapter","type-chapter","status-publish","hentry","contributor-dr-r-baskaran"],"part":3,"_links":{"self":[{"href":"https:\/\/ebooks.inflibnet.ac.in\/csp8\/wp-json\/pressbooks\/v2\/chapters\/122","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/ebooks.inflibnet.ac.in\/csp8\/wp-json\/pressbooks\/v2\/chapters"}],"about":[{"href":"https:\/\/ebooks.inflibnet.ac.in\/csp8\/wp-json\/wp\/v2\/types\/chapter"}],"author":[{"embeddable":true,"href":"https:\/\/ebooks.inflibnet.ac.in\/csp8\/wp-json\/wp\/v2\/users\/4"}],"version-history":[{"count":5,"href":"https:\/\/ebooks.inflibnet.ac.in\/csp8\/wp-json\/pressbooks\/v2\/chapters\/122\/revisions"}],"predecessor-version":[{"id":387,"href":"https:\/\/ebooks.inflibnet.ac.in\/csp8\/wp-json\/pressbooks\/v2\/chapters\/122\/revisions\/387"}],"part":[{"href":"https:\/\/ebooks.inflibnet.ac.in\/csp8\/wp-json\/pressbooks\/v2\/parts\/3"}],"metadata":[{"href":"https:\/\/ebooks.inflibnet.ac.in\/csp8\/wp-json\/pressbooks\/v2\/chapters\/122\/metadata\/"}],"wp:attachment":[{"href":"https:\/\/ebooks.inflibnet.ac.in\/csp8\/wp-json\/wp\/v2\/media?parent=122"}],"wp:term":[{"taxonomy":"chapter-type","embeddable":true,"href":"https:\/\/ebooks.inflibnet.ac.in\/csp8\/wp-json\/pressbooks\/v2\/chapter-type?post=122"},{"taxonomy":"contributor","embeddable":true,"href":"https:\/\/ebooks.inflibnet.ac.in\/csp8\/wp-json\/wp\/v2\/contributor?post=122"},{"taxonomy":"license","embeddable":true,"href":"https:\/\/ebooks.inflibnet.ac.in\/csp8\/wp-json\/wp\/v2\/license?post=122"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}