Requirement Engineering

Assignment - II
Iqbal Uddin Khan

Requirement Engineering

1 Give details of a RE Process Improvement Model. Select a model other than the model we discussed in class. Answer : What is process improvement? Process improvement means making things better, not just fighting fires or managing crises. It means setting aside the customary practice of blaming people for problems or failures. It is a way of looking at how we can do our work better. However, when we engage in true process improvement, we seek to learn what causes things to happen in a process and to use this knowledge to reduce variation, remove activities that contribute no value to the product or service produced, and improve customer satisfaction. A team examines all of the factors affecting the process: the materials used in the process, the methods and machines used to transform the materials into a product or service, and the people who perform the work. How does an organization get started on process improvement? An essential first step in getting started on process improvement is for the senior leader to make it a command priority. The importance of process improvement must be communicated from the top. Leaders need to foster an organizational environment in which a process improvement mentality can thrive and people are using quality-related tools and techniques on a regular basis. Now moving forward What is in the Basic Process Improvement Model? The Basic Process Improvement Model has two parts: A process simplification segment outlining steps 1 through 7 of the process improvement cycle is placed on the left. Teams begin process improvement activities with these steps. Depending on the stability and capability of the process, the team may continue on to step 8, or go directly to step 14. A Plan-Do-Check-Act (PDCA) Cycle consisting of steps 8 through 14 flows from the process simplification segment.

Using all 14 steps of the model will increase the teams process knowledge, broaden decision-making options, and enhance the likelihood of satisfactory long-term results. Lets take a quick look at whats in each of the steps in the model, mentioned in a table on next page.

Requirement Engineering

Step #
1

Description
Select the process to be improved and establish a well-defined process improvement objective. The objective may be established by the team or come from outside tasking. Organize a team to improve the process. This involves selecting the right people to serve on the team; identifying the resources available for the improvement effort, such as people, time, money, and materials; setting reporting requirements; and determining the teams level of authority. These elements may be formalized in a written charter. Define the current process using a flowchart. This tool is used to generate a step-by-step map of the activities, actions, and decisions which occur between the starting and stopping points. Simplify the process by removing redundant or unnecessary activities. People may have seen the process on paper in its entirety for the first time in Step 3. This can be a real eye-opener which prepares them to take these first steps in improving the process. Develop a plan for collecting data and collect baseline data. These data will be used as the yardstick for comparison later in the model. This begins the evaluation of the process against the process improvement objective established in Step 1. The flowchart in Step 3 helps the team determine who should collect data and where in the process data should be collected. Assess whether the process is stable .The team creates a control chart or run chart out of the data collected in Step 5 to gain a better understanding of what is happening in the process. The followon actions of the team are dictated by whether special because variation is found in the process. Assess whether the process is capable .The team plots a histogram to compare the data collected in Step 5 against the process improvement objective established in Step 1. Usually the process simplification actions in Step 4 are not enough to make the process capable of meeting the objective and the team will have to continue on to Step 8 in search of root causes. Even if the data Indicate that the process is meeting the objective; the team should consider whether it is feasible to improve the process further before going on to Step 14. Identify the root causes which prevent the process from meeting the objective. The team begins the Plan-Do-Check-Act Cycle here, using the cause-and-effect diagram or brainstorming tools to generate possible reasons why the process fails to meet the desired objective. Develop a plan for implementing a change based on the possible reasons for the processs inability to meet the objective set for it. These root causes were identified in Step 8. The planned improvement involves revising the steps in the simplified flowchart created after changes were made in Step 4. Modify the data collection plan developed in Step 5, if necessary. Test the changed process and collect data. Assess whether the changed process is stable .As in Step 6, the team uses a control chart or run chart to determine process stability. If the process is stable, the team can move on to Step 13; if not, the team must return the process to its former state and plan another change. Assess whether the change improved the process. Using the data collected in Step 11 and a histogram, the team determines whether the process is closer to meeting the process improvement objective established in Step 1. If the objective is met, the team can progress to Step 14; if not, the team must decide whether to keep or discard the change. Determine whether additional process improvements are feasible. The team is faced with this decision following process simplification in Step 7 and again after initiating an improvement in Steps 8 through 13. In Step 14, the team has the choice of embarking on continuous process improvement by reentering the model at Step 9, or simply monitoring the performance of the process until further improvement is feasible.

3 4

9 10 11 12

13

14

Requirement Engineering

Below is the Flowchart of Basic Improvement model.

Requirement Engineering

2 How can we do Requirement Modeling? List down the names of various requirement modeling techniques. Briefly explain any one of them. Answer: Requirements models will be used to control specialists such as integrated circuit designers and software programmers. Requirements models will inform them about their portion of the development and how it fits within the overall system. Requirements modeling supports upgrading and re-engineering of systems by offering the sustainers a clear and concise picture of everything that the system does, how it is verified, how it interfaces within itself and with other systems, and the constraints and boundaries that it is expected to operate within. Requirements models will be used by component vendors in lieu of or in addition to data sheets to describe their products. Because system requirements touch everything and everyone associated with a products development, the benefits of requirements modeling technology are wide reaching. Requirements models are human and computer readable engineering specifications. Having system and component specifications that can be interpreted by a computer will open many doors for complexity mitigation and automated analysis and engineering. Requirements modeling technology will bring about many new engineering tools and enhancements to several others. Some completely new tool types that are envisioned include: User friendly tools for capturing and viewing requirements models: 1. Simulation and animation tools for behavioral/operational requirements. 2. Requirements analysis tools for checking completeness, consistency, redundancy, etc. of requirements models. 3. Non Functional requirements. 4. Constraint checkers that check the design against the constraint. 5. Test plan, test pattern, test program and test model generation tools. 6. System synthesis tools. 7. Component and intellectual property search and retrieval tools. 8. Hardware/software and analog/digital partitioning tools that help determine the best implementation technology to meet the systems requirements. Tool categories that will be enhanced to support requirements modeling are: 1. 2. 3. 4. Requirements management tools. Formal model checkers. Formal functionality comparison tools. Application specific integrated circuit, field programmable gate array, and programmable logic device synthesis tools. 5. Software auto coding tools. 6. Cost modeling tools. 7. Other engineering analysis and modeling and simulation tools.

Requirement Engineering

Non Functional Requirements Non-functional requirements are properties and qualities the software system must possess while providing its intended functional requirements or services. These types of requirements have to be considered while developing the functional counterparts. They greatly affect the design and implementation choices a developer may make. They also affect the acceptability of the developed software by its intended users. 3 Write the names of various case tools. Give details about any one case too; related to RE. Answer: Computer Aided Software Engineering (CASE) tools are gradually becoming popular for the development of software as they are improving in the capabilities and functionalities and are proving to be beneficial for the development of quality software. CASE tools support almost all the phases of the software development life cycle such as analysis, design, etc., including umbrella activities such as project management, configuration management etc. The CASE tools in general, support standard software development methods. The CASE tools follow a typical process for the development of the system, for example, for developing data base application, CASE tools may support the following development steps: Creation of data flow and entity models. Establishing a relationship between requirements and models. Development of top-level design. Development of functional and process description. Development of test cases.

Below are the few listed CASE tools: CERN's Software Development Tools Duvessa Software Kestrel Interactive Development System Semantic Designs, Incorporated

Semantic Designs Semantic Designs produces the Design Maintenance System (DMS), a software engineering environment that supports the incremental construction and maintenance of large application systems and is driven by semantics and captured designs. DMS records what the software is supposed to do (specification), how the software does it (the code), and why the software works correctly (the design). Using practical program generation and transformation technology, DMS will enable designers to understand the design, and modify the design to obtain new code.

Requirement Engineering

4 What IEEE standard is available to write SRS? Write name of IEEE standard and give its contents in detail. Answer: A software requirements specification (SRS)has IEE standard declared as IEEE Standard 830-1998, a requirements specification for a software system, is a complete description of the behavior of a system to be developed and may include a set of use cases that describe interactions the users will have with the software. In addition it also contains non-functional requirements. Non-functional requirements impose constraints on the design or implementation. The software requirements specification document enlists all necessary requirements that is required for the project development. To derive the requirements we need to have clear and thorough understanding of the products to be developed. This is prepared after detailed communications with project team and the customer. An example organization of an SRS also known as SRS IEE template is as follows: 1. Introduction
a) b) c) d)

Purpose Definitions System overview References

2. Overall description
a)

Product perspective
I. II. III. IV. V. VI. VII. VIII.

System Interfaces User Interfaces Hardware interfaces Software interfaces Communication Interfaces Memory Constraints Operations Site Adaptation Requirements

b) c) d)

Product functions User characteristics Constraints, assumptions and dependencies

3. Specific requirements
a) b) c) d)

External interface requirements Functional requirements Performance requirements Design constraints

I.

Standards Compliance

e)

Logical database requirement

Requirement Engineering f)

Software System attributes

I. II. III. IV. V.

Reliability Availability Security Maintainability Portability

4. Other requirements.

References:
1 Hand Book for Basic Process Improvement. 2 vedyadhara.ignou.ac.in/wiki/images/0/05/B3U3mcs-034.pdf 3 REQUIREMENTS MODELING TECHNOLOGY A VISION FOR BETTER, FASTER, and CHEAPER SYSTEMS by Darrell Barker. 4 CAPTURING NON-FUNCTIONAL SOFTWARE REQUIREMENTS USING THE USER REQUIREMENTS NOTATION by K. Saleh and A. Al-Zarouni. 5 https://sw.thecsiac.com/databases/url/key/153/158#.UQrrlWdIVOw 6 http://asingh.com.np/blog/ieee-srs-recommendations/ 7 http://en.wikipedia.org/wiki/Software_requirements_specification

Requirement Engineering