Software Requirements Management Process - Report Example

Name: Tutor: Title: Sоftwаrе Rеquirеmеnts Маnаgеmеnt Рrосеss Course: Date: Sоftwаrе Rеquirеmеnts Маnаgеmеnt Рrосеss 1. Introduction Software projects are gradually becoming complex and thus the amount of requirements in software projects increase considerably, requiring regular changes and complex relationship among requirements. Sоftwаrе rеquirеmеnts mаnаgеmеnt prосеss involves defining, recognizing, modeling, linking, documentation and maintenance of software requirements to assist in understanding the problem better. There are various techniques integrated within requirement management process to guarantee the entirety compatibility, comprehensibility, as well as precision of requirements. Basically, success of all software projects is examined by taking into consideration level of meeting the objectives of the project. Accordingly, requirement management is a procedure of discovering these objectives that completed through identification of stakeholders, their requirements, and documentation of the requirements, in a way that responds to analysis, communicating and implementation of the requirements (Ramsin & Paige, 2008). 1.1 Software requirement engineering challenges According to statistics, the main cause of software failure is the presence of defects in software requirement. Due to this, it is very necessary and important to run Requirements Management in software projects. Requirements Management tools like Telelogic DOORS, Rational Requisite Pro, and RTM have taken place since 1980s and requirement management processes differ in various software processes. Nonetheless, requirements management tools based on content management do not have any relationship with software process, in particular lack of efficient mechanism when handling requirements change within customer-oriented projects which continuously change their requirements. Therefore, there is a need to develop requirements management scheme allied to software process in order to improve the quality of project management and software products (Zhu, Jiang & Liu 2008). 1.2 The importance of software requirements engineering The need to define software requirement lies in the requirement to pass various phases. Requirement definition is important in identifying requirement of stockholders, their validation, as well as provision of agreement on requirements of developing system. Generally, requirements engineering is important in software requiring high costs to maintain and support for a long time. In the development of such projects, it is necessary to classify, combine, and prioritize functional and non functional requirements, co-requisites, and pre-requisites, in addition to different requirements (Ramsin & Paige 2008). Requirements engineering process assists in categorizing requirement. This means that all requirements during the life cycle of the software should be seen, regardless if they are vital and necessary for the software at present or in future. Utilizing requirements engineering entirely and appropriately, there are likely to be less fails, and an organization cannot lose its capital, profits, marketing, and resources as well. In addition, requirements engineering process is important in discovering defects earlier during the development process, maintaining product definitions, and also communicating change to the development team (Ramsin & Paige 2008). 2. Software Requirements Management best practices Requirement management best practices consist of strategies for: Requirement types whereby forms of requirement classifies requirements Requirement traces whereby the requirement traces help through managing effect of change, ensuring completeness and providing justification Requirement baselines whereby it represents agreements  The following roadmap represents: Requirement types (Requirement Type Strategy) Predictable relationships between requirements types (Requirement Trace Strategy) Directive to have 'early and often' agreements (Requirement Baseline Strategy (Flores 1998) Figure 1: Requirement management best practices consist of strategies (Zhu, Jiang & Liu 2008). Prior to the development of the software, the customers, users as well as the suppliers of the software product should establish and agree regarding the requirements. The requirements determine “what” of a software product as illustrated below: What the software should do in adding value to its stakeholders and these functional requirements establish the competence of the software product What software should be in adding value to its stakeholders and this includes non-functional requirements defining aspects and qualities that the software product has. As a result, they determine the functionality of the software product. What limitations are there regarding the choices that developers have during the software implementation? Generally, the external interface definitions as well as other restraints establish the limitations (Zhu, Jiang & Liu 2008). Table 1: Requirement Types Requirement Type Tells about…. Business requirement Targeted goal User requirement The task that the user should perform to achieve the business goal Functional requirement What the software should do to add value to its stakeholders Non-functional requirement What software should be to add value to its stakeholders Business rule The standard rule that the system should follow Data requirement The required information by the system to perform its functions Constraint Limitations on the system Basically, recognizing that there are various types of requirements and levels is important in comprehending the information required to obtain, analyze, and certify the software requirements (Westfall 2006). Business requirements identify the business problems that need the solutions as well as the business opportunities that the software product presents. Business requirements establish the reason behind the software development and they are generally stipulated in terms of the goals of the client or company that needs the software to be developed (Westfall 2006). User requirement analyses the functioning of the software product according to the perception of the user and therefore defines what the software product should do for the users to achieve their goals. On the other hand, business rules include the regulations defining how users carry out business and hence they are regarded as user-level requirements. Accordingly, the software product should follow the rules for it to function properly within the domain of the user. Non-functional requirements include the user-level quality characteristics defining the quality of the software product. Non-functional requirements encompass dependability, availability, security, safety, maintainability, portability, usability, and other similar characteristics. The functional requirements identify what the software is supposed to do for the users to achieve their objectives. In some instance, numerous user level requirements can be necessary to meet a single business requirement (Sommerville & Sawyer 1997). On the other hand, the constraints identify the limitations in the choices that the supplier makes during the designing and the development of the software product. For instant, there can be a requirement that the software product should only use less than 50% of the availability memory in to make sure that there is a room for future improvement on the software product. The data requirements establish the particular data items that should be incorporated as component of the software for it to function appropriately (Hupe, Wegner & Matthes 2008). Normally, the software can be a component of a much bigger system that consists of other parts. In such a case, the business requirement, along with user requirement are feed into the software product requirements at the system level. As a result, the system design distributes requirements from the combination of system requirements downward into the software, hardware, as well as manual operations elements (Ramsin & Paige 2008). 3. Benefits of a process-oriented engineering approach A process-oriented engineering approach results to reduced maintenance, code reusability, enhanced reliability, as well flexibility. The following are some of the benefits of a process-oriented engineering approach: Reduced Maintenance: The key objective of a process-oriented engineering approach is the guarantee that the software system will have a longer life and at the same time have reduced maintenance costs. Since most of the processes in the software system are encapsulated, the behaviors can be reprocessed and utilized incorporated into new behaviors. Real-World Modeling: A software system made using a process-oriented engineering approach tends to be in the real world in a more complete fashion. Systems are organized into categories of entities and entities are linked to behaviors. This means that the system is based on the engineering objects (Matthes 2004). Improved reliability and flexibility: A process-oriented engineering approach is extremely reliable since new behaviors can be integrated from the existing system. Since it is possible to dynamically access the system, it is possible to create a new object any time. The new object can succeed data characteristics from one, or several other objects. Additionally, behaviors might be inherited from super-classes, and it also possible to add novel behaviors without having any effect on the existing systems functions. High code reusability: With the creation of new objects using a process-oriented engineering approach, data characteristics of the class from which it was spawned are routinely inherited. In addition, the new object inherits the data and behaviors from each and every super-class in which it takes part. As a result, when a user creates a new form of widget, the behavior of the new object is “wigitty”, whereas containing new behaviors that are defined to the system (Green 2008). A process-oriented engineering approach is also important in identification of all requirements of the various stakeholders and this helps in preventing software product requirements from being neglected. For instance, if an organization is developing a payroll and fails to identify charities as being one of the stakeholders, the system might exempt the requirements for the software to: Enable the payees to identify charitable deductions Hold back charitable deductions from the checks of payee every pay duration Report existing and year-to-date charitable deductions on the pay slip of the payee Print a check to all charities for the accrued amount withheld from payees. Through identification and involvement of the major stakeholders, the analyst is able to access their experience base as well as domain understanding. The work of the analyst is conducting analysis, expansion, synthesis, conflicts resolutions, as well as combination of the inputs from each and every stakeholder into a structured set of requirements at the suitable level of concept for the target audience (Westfall 2006). Another benefit is that identification of the stakeholders long with their involvement in the requirements engineering process combines various perspectives that can help in a more complete set requirements during the early part of software development. Generally, involving stakeholders does away with the necessity of having two of the most unproductive requirements elicitation performances, namely: clairvoyance and telepathy (Zhu, Jiang & Liu 2008). A process-oriented engineering approach also helps in obtaining stakeholder input as well as involving them in getting a solution to their needs. As a result, involved stakeholders have a higher likelihood of buying in to the complete software product, and this can result to development of champions for the software product within the stakeholder society. The benefit of this is in transitioning the software product into the operational setting. This is because the ultimate decision is determining the priorities of the stakeholders basing on their comparative significance to the success of the software product. In essence, determined priorities assist in establishing the one to listen to in case of a conflict between the needs of different stakeholders (Wiegers 2003). 4. Requirement management process definition for small projects 4.1 ETVX process definition This process encompasses the definition of Entry criteria, Tasks, Verification and eXit criteria for a process. The justification for this process is that it is simple and thus suitable for a small group project because it is cost effective and also does not require much time to learn special techniques and tools. Additionally, implementation of this process can be done utilizing basic PC based word processing and graphics tools such as Microsoft Word and PowerPoint and the tools are readily available to almost everybody. 4.2 Key activities Writing the initial project plan Writing a requirements management plan which will describe the actual requirement on traceability, the requirement information (attributes) to be maintained Writing the document quality characteristics Defining the individuals involved within the project and their responsibilities Creating a requirements database (Westfall 2002). 4.3 Inputs Entry criteria Entry criteria refer to specific, measurable conditions that are supposed to be fulfilled prior to the start of the process and can consist of: Work products that should be completion, endorsed or placed under configuration control Tasks that should be completed adequately Specific measured values that should be attained Individuals available to carry out the process Available individuals to carry out the process (Westfall 2002). Process Flow Diagram The first step here involved defining the various roles of the process. A process flow diagram will be made to indicate the relationship between the different task and through illustrating individuals responsible for every task. Process Flowchart This can be drawn to show the different tasks, verification steps, decisions, as well as deliverables of the process. This process will make it simpler for people allotted to a role to identify their responsibilities. Tasks and Verification A task refers to the work that should be done to complete a process. On the other hand, verification refers to the actions that will be performed to examine the outcome of the project tasks to establish if the requirements have been fulfilled. Tasks and verification will include: Detailed work instructions describing how the tasks/verification steps will be achieved and this includes specific techniques to be utilized Pointers to standards to be utilized during the task/verification step or during output creation Pointers to standardized templates for developing outputs of the tasks/verification step Describing metrics allied to the task/verification step Other resources such as tools, hardware that should be availed (Humphrey 1989). Exit criteria This refers to the specific, measurable conditions that are supposed to be fulfilled prior to the completion of the process. 4.4 Outputs Deliverables Deliverables include the tangible, physical objects achievements that are the outcomes of the tasks in the project. Basically, deliverables are the intended outputs from the project processes. Quality records These are the secondary outputs that will give evidence that the suitable activities were performed and that execution of these activities fulfilled the required standards. Example of quality record for the project encompass: test logs, minutes from meetings, engineering notebooks, action item lists, and status reports. For all quality records, the following will be listed: The responsible role for collecting that record The location where the record will be maintained, for instance project file or specific database The time duration that the record will be available for access 4.5 Tools Basic PC word processing Graphic tools such as Microsoft Word and PowerPoint These tools are readily available and this will allow easy documentation and maintenance of the project processes with minimal additional skills training and expense (Humphrey 1989). 4.6 Measurements Percentage of changed requirements per requirement type This measurement indicates the stability of the requirements. Because both the developmental team and the test team maintain their own set of requirements, both the teams measure on the requirements that are allotted to them. Basically, the developmental team delivers requirements measures, as provided in Error! Reference source not found. The tests team as provided in Error! Reference source not found. If the collection of data is done often, it is appropriate to make trend graphs, to reflect the stability of requirements with time. The rationale of using this measurement is that the percentage of changed requirement per requirement type shows the stability of the requirements. This is done once per week and changed requirement is defined as the requirement from which the text is changed. Trend graphs Trend will provide the stability of the requirements with time. Basically, the rationale of using this measurement to indicate the stability of the requirements as the project goes on and this is done once per week (Westfall 2002). 5. Conclusion In conclusion, what defines business problems that need solutions or business opportunities to be handled by the software product are the business requirements. Generally, the business requirements define the development of the software product and thus the business requirements are stipulated in terms of customer’s/organization’s objective asking for the software development. User requirements consider the software product functionality from the angle of the user. The functional requirements identify what the software is supposed to do for the users to achieve their objectives. In some instances, numerous user level requirements can be necessary to meet a single business requirement. Therefore, there is need a need to develop the right software requirements for organizations to get the software they need. It is important to comprehend the different types and levels of requirement to carry out a good job of requirements engineering. The benefits of good requirements should be understood in order to dedicate enough resources and time to the requirements engineering process during the entire period of software development. As mentioned before, requirements management entails an interdisciplinary approach that takes into account of all stakeholder groups. Additionally, it requires proficiency in different skills of requirements engineering which includes requirements elicitation, requirements analysis, requirements specification, requirements validation, as well as requirements management. Bibliography Green, S., 2008, Goal-Oriented Approaches to Requirements Engineering, University of the West of England, England. Flores, F., 1998, Computer systems and the design of organizational interaction, ACM Transactions on Office Information Systems, Vol. 6/2. Hupe, P, Wegner, & Matthes, F., 2008, A Process-oriented Approach to Software Component Definition, Software Systems Institute, Hamburg. Humphrey 1989, Watts Humphrey and Marc Kellner, Software Process Modeling: Principles of Entity Process Models, Matthes, F., 2004, A high level system model for agent coordination, Springer, Colorado. Pyzdek, T., 2000, Quality engineering handbook, Marcel Dekker, New York. Ramsin, R, & Paige, R., 2008, Process-centered review of object oriented software development methodologies, ACM Computing Surveys, Vol. 40/I. Sommerville, I & Sawyer, P., 1997, Requirements engineering: a good practice guide, John Wiley & Sons, New York. Westfall, L, 2006, Software Requirements Engineering: What, Why, Who, When, and How, Westfall Team, Texas. Westfall, L., 2002, How to Create Useful Software Process Documentation, The Westfall Team. Wiegers, K. E., 2003, Software requirements, Microsoft Press, Redmond, Wash. Zhu, C, Jiang, Y, & Liu, L., 2008, Process-Related Software Requirements Management, Anhui Agricultural University, Hefei, China. Read More