Software Requirements Management - Report Example

SOFTWARE REQUIREMENTS MANAGEMENT PROCESS By Name Course Instructor Institution City/State Date 1.0 Introduction Requirements define the potentiality that the systems need to deliver, and kowtow or deficiency of conformance to requirements set, which mostly establishes the success or failure of software development. Essentially, requirements are those superficially apparent facets of a system that a user, customer, or other stakeholder wishes to have present in his system (Pfahl & Lebsanft, 2000, p.1002). In this regard, requirements management is the set of activities surrounding the compilation, control, examination, filtering, and documentation of a system’s specifications. What’s more, requirements management comprises of three activities: Requirements elicitation, an art of comprehending the requirements of stakeholders, and gathering them in a warehouse for future examination. The second activity is Requirements Triage, an art of resolving which aspects are the suitable features to incorporate in the product. Lastly, Requirements Specification, an art of detailing the precise external activities of a system that will take in hand the attributes chosen during the triage process. In essence, software requirement management is a typical process in the domain of software engineering employed in software development (Davis et al., 2000, p.1). Furthermore it is an incessant process all through the existence of the software development and being a process, it involves software requirements collection, analysis, traceability, prioritization, and managing of alterations. 2.0 Software requirement engineering challenges Errors in requirements hardly are recognized during development instead they remain hidden until system turns out to be functional; thus, customer requirements are not met. According to Asghar and Umar (2010) deprived requirements steers requirement specifications changes and needs re-designing, re-implementing and retesting for the whole software. As a result, requirement engineers have to thrash about and surmount numerous challenges for development of effectual and resourceful software. Arguably, Asghar and Umar (2010) posit that requirement engineering challenges will award chances for requirement engineers to improve software accomplishment tempo. Reference argues that there have been numerous studies performed to investigate diverse challenges in various requirement engineering domains, but these studies only recommended paradigms and offered suggestions to overpower challenges in a single domain of requirement engineering. According to reference, challenges based on requirement engineering can be grouped in seven components namely technological crisis, external events, economic crisis, requirement engineering process, organizational issues, time, and stakeholder’s conflicts (Asghar & Umar, 2010, p.43). Figure 1: Requirement Engineering Challenges Framework (Asghar & Umar, 2010) Technology: Archaic requirement engineering contrivance may fail to offer accurate performance for example, requirement paraphernalia for development of models or incentives. Asghar and Umar (2010) posit that removing these requirements engineering tool entirely and installing novel tool may fail to change or emulate the file. Economic Crisis: Vague challenges in the IT market may augment in general the cost of software, For example, indistinct software requirements may augment maintenance cost. What’s more, developers or customers may endure financial collapses during software development. Besides, growth in accounts billed, out of control expenditure and inadequately premeditated budgeting strategies can instigate impoverishment to the customer or organization. External Events; Aimed efficiency in software can be attained if challenging outside threats is solved in advance. According to Asghar and Umar (2010), unintentional removal of valuable information, virus-infection, file corruption, or failure of the hardware may generate cataclysm state for requirement engineers Requirement Engineering Process: Achieving and understanding requirements for multifaceted areas or decisive systems have for all time provided immense challenges for requirement engineers. Moreover, stakeholders do not express their requirements accurately during requirement definition process. Consequently, requirement specifications are indistinct, mystifying and indefinite; thus, decomposition, requirements modeling and recognition of business procedures turns out to be intricate (Asghar & Umar, 2010, p.44). Organizational: Software applications are designed from teamwork of both the business and IT strategies, but regrettably there is wide-ranging multiplicity of insights within organizational units. For this reason, aligning and synchronizing strategies suggested by various organisational units grow to be decisive assignment for requirement engineers (Asghar & Umar, 2010, p.45). Stakeholders: Insufficient technical expertise with requirement engineers and inadequate domain familiarity can have an immense effect on software. According to Asghar and Umar (2010), requirement engineers are incapable to sufficiently take in hand the predicaments and end user’s desires. Therefore, unproductive functionality by requirement engineers may lead to obsolete and bug prone requirements. Time: Normally the time needed to complete tasks during requirement engineering stage is undervalued and for this reason delivery of targets is held up, mainly when tasks are on vital trail. In this regard, requirement engineers begin to pursue short cuts or at other times disregard to accentuate and concentrate on main aspects. As a result, requirements are scantily developed or gets behind program, which in turn, lead to downstream breakdown of whole software (Asghar & Umar, 2010, p.46). 2.1 Requirements Elicitation Requirements elicitation, as stated earlier is an art of comprehending the requirements of stakeholders, and gathering them in a data warehouse for future examination. The candidates for this process may be possible clients, existing clients, sales win/loss reports, customers’ clients, promotion, change demands, problem reports, elements discarded from previous releases, in-house development workers, production, customer support staff, innovators in the corporation, or administration. Software requirements must take in hand the entire extent of the development attempt, including the computing setting, the product and its interfaces, and after development procedures. Procedural schedules are obtained from the software requirements, and the advancement of the project team toward accomplishing project goals is evaluated against the procedural plans (Davis et al., 2000, p.2). According to CMMI (2010), the change suggestions unswervingly engross novel or alterations to the requirement baseline that can be recommended by any stakeholder. Arguably, change demands influences the software product design that is articulated by the product structural design, which is obtained from the software requirements and is defined by the data package of the software. Stakeholder’s needs and anticipations allurement is essential to comprehend the software product’s rationale, roles, elements, and functionality attributes that establish the software requirements and project span. Paraphernalia are accessible to support in a diversity of elicitation methods, for instance, Computer- Assisted Cooperative Work (CSCW) paraphernalia can make easy brainstorming conferences regardless of whether the stakeholders are located in one area or are physically dispersed (Davis et al., 2000, p.3). In addition, forms such as the Bosworth pain sheet while not computerized to our understanding can be employed with no trouble to systematize and examine twinges, effects, competition, and preparations. Furthermore, On-line polling paraphernalia can be employed to collect views of various stakeholders; thus, is helpful in conducting surveys. According to Davis et al. (2000), requirements elicitation is the trickiest in comparison with the other requirements management activities since the developers are generating something from zilch. The outcome of elicitation is a register of candidate characteristics, each interpreted with comparative procedural threat, an approximation of effort needed to deal with the feature, and a comparative precedence or measure of significance from the clients’ perspective and tools subsist to document this outcome. The tools vary from indispensable tools such as spreadsheets, word processors, and databases, to undemanding requirements definite warehouses like Omni-Vista RM11, to more multifarious requirements management tools like Rational RequisitePro12, and TBI Caliber14 (Davis et al., 2000, p.3). Fig 2: Three Stage Requirements Elicitation Paradigm (Yang & Tang, 2003) 2.2 Requirements Specification Requirements specification is the task of recording the accurate external deeds of the system that is to be developed and it takes the attributes chosen during requirements triage and inflates them into substantial feature. The main rationales of doing this are to make sure that firstly, both clients and developers have similar comprehension of what is to be developed, secondly, every developer has matching comprehension of what is to be developed. Thirdly, examiners are testing for the equivalent qualities that developers are developing, and lastly, administration is using resources to the similar set of tasks that the developers are doing. What’s more, all documented requirements must be accurate, reliable, explicit, and verifiable (Davis et al., 2000, p.4). Habitually, these requirements were recorded in a software requirements specification, but lately there is a tendency toward the requirements in both the database and warehouse of isolated requirements, instead of a recognized document. Several tools that exist to document these interpreted requirements include Rational RequisitePro22, Omni-Vista RM21, and TBI Caliber24. Fig 3: Requirement Specification process (Source: w3.org) 3.0 Overview of Software Requirements Management The intricacy connected with the software design, solution must be comprehended before the requirements are base-lined and laid under formation control. Additionally, requirements examination must weigh up the likelihood of gratifying the entire set of software requirements in program cost and plan restraints. Arguably, this can merely be accomplished by analyzing the solution space for all requirements and connecting the predisposition of project variables to various functionality levels (CMMI, 2010, p.283). Fig 4: Requirement Management Activities (source: kovair.com) 3.1 Requirements Triage Requirements triage is the procedure of resolving in particular which product is to be developed and from a development manager’s viewpoint, triage is somewhat uncomplicated. Furthermore, Development managers guesstimate the exertion and time needed to fulfill the recommended attributes. According to Pfahl and Lebsanft (2000), the development manager contrasts these with the resources and plans provided to them and if they are not well-matched, they can purely take out features until the project concerned is well-matched with the provided plan and budget. Arguably, taking out features may have an affirmative affect on development threat, but this sense totally pay no attention to effects on market, cost, income, and earnings. Therefore, requirements triage should take into account the marketing, economic as well as the development aspects. Based on reference study, the key goal of requirements triage is rather clear-cut: providing a set of features, which can be enforced through accessible resources and with satisfactory levels of threat. Furthermore, requirements triage ensures the product generated can be sold at an up to standard price to a recognized market, in sufficient quantities to attain tolerable levels of income and earnings, and as a result attain a sensible income on investment. Tools accessible to help in some facets of requirements triage include Omni-Vista SP16, which permits clients to view the results of features, budget, and cost of products sold on returns, threat, earnings and income on investment. QSS Tech Plan 218, which permits clients to contrast the outcomes of decisions on tools, threat, and promotion. On the other hand, primavera Monte Carlo 3.017 permits clients to assume in due course the effects of building fundamental product planning decisions (Davis et al., 2000, p.4). 4.0 Benefits of a process-oriented engineering approach Process oriented approach refers to the software development process in dexterity with the procedure of human erudition, effort and interaction that takes place in a developing world where requires alteration. Possibly, this approach acclimatizes documentation in a properly and controlled way as well supports structured communication with precise project team functions, conquers difficulties like intricacy and unpredictability (Sampson, 2008, p.3). Taking into account one out of various noteworthy perspectives of running businesses at the moment, it has been evaluated that the businesses at present have a growing concentration towards business processes that create value for the clients. As a result, managers are making sure that business value is created as ably as possible while decreasing unnecessary behavior and for that reason, it is important that the IT support system of a company interconnect with the business procedures in an enhanced manner. The process oriented approach according to reference conceptualizes that business procedures should be observed as a unified tasks set that are carried out to achieve the business objective and goal (Sampson, 2008, p.6). Sampson (2008) affirms that since diverse business activities such as procurement, human resources, and internal processes are connected with a business process all harmonized towards a mutual goal. In this regard, an organization is viewed as a group of aptitude centers sharing similar objectives as a procedure takes place. From a software development perspective, the process- oriented approach ensures that the developer retains a control over diverse activities that are being performed so that the final product quality is not compromised. While tackling the intricacy of software, process oriented approach reduces the number of interfaces through incorporation of vital message broker and for this reason making it easier to maintain the interfaces. Consequently, when one of the systems is needed to be altered, merely one link is needed to be altered. Furthermore, the quandary of invisibility is tackled by summarizing the rational communication amid the systems, making it probable to analyze, reproduce, model and alter the communication using graphical interface in opposition to process paradigms. It is for that reason bickered that visualization reduces intricacy and offers room for hasty and supple alterations to the business processes braced by the system. Sampson (2008) study notes that process oriented approach solves the conformity issues within a project setting instead of the speculative insinuations of the approach. Having said so, virtually albeit the approach needs the developers to play the game within the industrial paradigms or standards; yet, the software developers must be suitably skilled and qualified to comprehend the cost of non-conformance. 4.0 Requirement management process definition for small projects The intention of requirements management is to administer the project’s products requirement and modules and to recognize discrepancies amid those requirements and the project’s schedules and task products. According to reference, requirements Management are a process of ensuring that every requirement, as well as practical, non-technical, and managerial requirements is well administered (CMMI, 2010, p.342). Fig 5: Requirement management Process (Leffingwell & Widrig, 2000) 4.1 Process Steps Step one: Placing a novel requirement from an endorsed provider under configuration control. Step two: Achieving a clear comprehension on the meaning of the requirements between the user and the requirements providers. Arguably, after the project matures and requirements are obtained, extra requirements are needed. In this regard, the requirements Analyst should set up measures for determining satisfactory basis for requirements. Consequently, to steer clear of requirements skulk, the analyst should institute formal sources from which to collect requirements. Other activities involved in this step include setting up goals criteria for the approval of requirements since lack of approval criteria frequently leads to insufficient authentication, expensive rework, or client refutation. Furthermore, requirements analysis must be conducted to make sure they are practicable, well-matched, and all stakeholders share similar requirements meaning (CMMI, 2010, p.344). Step 3: Documenting requirements using verified requirements management tool after clear comprehension. Step 4: Managing requirements changes, which can be achieved by capturing and documenting all requirements changes received by the project. In this stage, the change source, history, and the basis must be maintained and the effect of requirement changes from the perspective of pertinent stakeholders must be documented. Furthermore, the requirement change data must be made accessible to project members. Step 5: Maintaining requirement traceability for all levels of product breakdown, wherein the requirements analyst upholds the traceability from the requirements to the project schedules and task products. In essence, traceability required in performing the impact evaluation of requirements changes on project schedules, work decomposition formation, and work products. Particularly the requirements analyst should maintain traceability and generate the requirements traceability matrix (CMMI, 2010, p.345). Step six: Recognizing inconsistencies (Validation) amid the project work of arts and the requirements, wherein the requirements analyst is expected to review the project artifacts for discrepancy, recognize artifacts sections that require change to make them steady with the requirements, and advise the project manager that counteractive measures required. Last step: Getting assurance to requirements (Verification) between those who performed the activities and project manager to enforce the requirements. In this regard, as requirements progress, the project manger should make sure that the project participants obligate to the existing, verified requirements and the consequential changes to project artifacts (CMMI, 2010, p.347). 5.0 Conclusion Conclusively, requirements are those superficially apparent facets of a system that a user, customer, or other stakeholder wishes to have present in his system. Requirements management comprises of three activities: requirements elicitation, requirements triage, and requirements specification. For management of software to be successfully, organizations must take into account process-oriented engineering approach, which ensures that the developer retains a control over diverse activities that are being performed so that the final product quality is not compromised. While tackling the intricacy of software, process oriented approach reduces invisibility, intricacy and offers room for hasty and supple alterations to the business processes braced by the system. In this regard, the intention of requirements management is to administer the project’s products requirement and modules and to recognize discrepancies amid those requirements and the project’s schedules and task products. 6.0 References Read More