Software Requirements Management - Report Example

Sоftwаrе Rеquirеmеnts Mаnаgеmеnt Student’s Name Subject Professor University/Institution Location Date Table of Contents Table of Contents 2 1.0 Introduction 3 1.1 Software requirement engineering challenges 4 2.0 Requirement Traceability 4 3.0 Best practices for the management of software requirements 5 3.1 Requirements Review 5 3.2 Development process 6 3.3 Architecture 6 3.4 Design and Coding 6 3.5 Testing and configuration 7 3.6 Deployment 7 4.0 Benefits of a process-oriented engineering approach 7 4.1 Concurrency 8 4.2 Communication 8 5.0 A simple process - small projects 8 5.1 Key activities 9 5.2 Inputs 10 5.3 Outputs 11 5.4 Tools 12 Conclusion 13 References 15 Appendices 17 1.0 Introduction Software requirements are the descriptions and specifications given by a stakeholder in relation to particular software reflecting their needs. These requirements are collected, specified, analysed, validated and recorded in a process called requirement engineering. This is what determines what is to be produced (Sohail & Umar 2010). Software requirement engineering is very important because it helps in development of effective softwares with reduced errors, from the early stage of the software development. This therefore gives owners a satisfaction that what they requested for is what they are getting. On the other hand, requirements management is a constant process undertaken all through a project. Simply put, a requirement is a propensity to which an outcome of a project must conform. Mainly, requirement management aims at making sure customers and stakeholders’ needs and expectations are verified, documented and met. This process begins with analyzing and elicitation of organizations constraints and objectives (Sohail & Umar 2010). Furthermore, Sohail and Umar, 2010 asserts that requirements management engages communication team members of the project and the stakeholders. It’s also constitutes adjustment to changes in requirements all thought the project course. This paper looks at software requirements management process. This paper begins by looking at software requirement engineering challenges. Secondly, the importance of requirement traceability to the process is analysed, and then best practices for the management of software requirements, followed by benefits of a process oriented engineering approach, and finally looks at requirement management process definition for small projects (CMMI Institute 2013) 1.1 Software requirement engineering challenges According to Damian, 2000 this process is not an easy task and it presents challenges with it. These include: - lack of a systematic process to capture the requirements. This problem is brought about by the different approaches which use various labels of capturing the requirements. Poor communication is another issue with the requirements engineering process. This is because people are known to be social beings and due to language barriers there might be failure of communication thus leading to misunderstood requirements. Other challenges are lack of appropriate knowledge, understanding in a differently from one means, documentation that is not complete or not appropriate. The problems may also include, poor management of resource and people whenever requirements are changed continuously and psychological and socio-technical problems. 2.0 Requirement Traceability In software development or systems engineering lies a sub field of requirements management referred to as traceability. Requirement traceability aims filing the life of a requirement. This helps in tracing back where each requirement originated from, whereas recording every change made to the requirement is documented to easy traceability (Redding et al 2008). Considering that requirements originate from diverse sources such from business people who are in need the product, managers as well as the actual users, this means the different requirements for the product are certain. Thus, use of requirement traceability ensures that tracking back of any implemented feature right from requirement elicitation is possible. For instance, during development process traceability can be used to enable prioritizing requirements as well ensuring the that value placed is the use to the requirement is always determined. In other words, requirement traceability emphasizes that even after deployment and use of implemented features, originality ought to be traced (Redding et al 2008). 3.0 Best practices for the management of software requirements Software requirements management is loaded with risks ranging from technical, financial, market risks among others. Therefore, for a project to be successful one needs to know what should be done and how to do it the best way. This means that though the process is fraught by challenges, these can be overcome by following the best practices. The following is an overview of the best practices for the management of software requirements. 3.1 Requirements Review Collection and approving requirements is essential to accomplishment of project. This means it is necessary to fix all requirements beforehand by gathering and studying stakeholders’ needs. According to (Miller 2004), requirements should be reviewed thoroughly to make sure that each requirement has all its details defined and that it is necessary for the development of the software and hence its release. Some things to be checked during the review process are that the requirement is sufficiently defined, whether it can be substituted and if it is in its simplest form. 3.2 Development process Development an apt lifecycle process is elementary, considering that all other activities are originated from the process. This process necessitates methodologies, and which must be appropriately executed. This can be done by defining a process, roles for each team, and artifacts among other things. If errors that happen in this stage are not detected then it could be very costly for the project when they are detected later (Adam 2008). 3.3 Architecture An appropriate architecture is fundamental for any application. Use of best architecture practices is helpful in reviewing a project in difficulty. Best architectures practices are known as patterns, and help in knowledge of will not work, and the reason why. The patterns EJB design, among others. Other best practices in relation to software requirements development include, choosing the best methodology such as spiral-based methodology; ensuring the architecture is the appropriate one for instance IEEE, java patterns among others. 3.4 Design and Coding Apart from a good architecture a good design is necessary alongside coding. Coding is the most significance part of the project and should be carried out with all accuracy. It is necessary to ensure an application is neither under designed nor over designed. The guiding principles in this area are keeping details simple and hide the information. And an object oriented analysis is necessary (Miller 2004). 3.5 Testing and configuration Configuration involves confirming and managing the condition of all artifacts making up the system. On the other hand, testing is a key part of software development, rather than an afterthought in case of a tightening schedule. Thus, as an integral part should be well planned and done proactively, before the start of coding. Analysis testing should be done after every step of development to ensure each part works appropriately. It is through testing that coding errors can be identified and therefore it is vital even though it has to be performed at the end of the project (Perks 2006). 3.6 Deployment Deployment is the last phase or releasing the software to the user. Bearing in mind that, things can still go wrong at this stage, the use of deployment checklist is recommended. Success of the application may then be measured against standards in an industry (Miller 2004). 4.0 Benefits of a process-oriented engineering approach Process oriented approach is beneficial in the senses that it is structured in terms of activities, events, dependencies on data flow, control and events. What’s more these activities can be decomposed into sub-processes. This creates alignment of the activities and resources. Moreover, through this type of approach a holistic view is generated in regard to activities and resources needed to achieve the goal. Accordingly, through simulation, an analysis of the process is made. Process oriented approaches result to workflow applications or they may also lead to other types of information systems that are process-aware (Redding et al 2008). In other words, process-oriented engineering approach contains the aspects of concurrency, isolation, communication, composition and reasoning. However, the two central portions of this process are concurrency and communication. 4.1 Concurrency The issue of concurrency deals with the breaking down of a problem into various activities and doing each activity so as to satisfy their relationships. The benefit of concurrency is that problems can be broken down into simple concurrent activities. Secondly, one does not need to worry about scheduling since the concurrent runtime will schedule activities itself (Sampson 2008). 4.2 Communication To avoid overriding of certain requirements on others, then, constants communication is of great essential for development team members. For instance, developing software for internal applications, the roust needs of business may lead to ignoring of user requirements. However, with dynamic communication, this is may not happen. Communication in software requirements engineering is also essential in order to understand the user’s needs, and therefore be able to make software that is suitable and satisfactory to the user. In other words, communication enhances quality of product by reducing risks in the project, improving collaborative development and clear projection of project goals. 5.0 A simple process - small projects This is a management plan for a temporary project which involved; compiling record management software (RMS). The project will be carried out for six months to with the objectives of assisting in developing and implementation of electronic document management. The system can then be used for keeping record, efficiency use, retrieval and sharing across the organization. Such a project is very important as it concurrently meets with the needs of most business today. The need to keep record of functions, and efficient use, sharing, retrieval and storage of organizational records can be hindered without systematic records software. This project is meant to integrate knowledge across an organization through sharing of resources and significantly reduce effort duplication, streamline information resources to support changing business goals and reduce inefficiency (Kavanagh & Thite 2008). 5.1 Key activities As Trace (2002) argues, the objective of the project is creation of new tools which are necessary to support in document keeping across an organization The tools should then be used by staff to meet the business needs, obligations, customer expectations with its relevant standards. Specifically the key activities in the project will involve a design and implementation plan involving: As in Fig.1.0 below, the methodology followed will involve some key stages to implement a recordkeeping system through the stages follows consecutively from: Investigation of a broad environment where an organisation carries its operations Analysis of organizational activities and functions which are routinely being performed Analyse and identify organizational requirements to make and keep the documents and records relating to its activities and functions. Assess the extent of the current system in meeting the document needs and requirements of an organisation. Identify strategies and select those which meet the requirements of records keeping. Design a system of record keeping to incorporate the above strategies Implement the system Evaluate its performance. The core activities which are directly related to software development, implementation and management will then follows as by further elaborated in Fig.2.0: Select and develop electronic document management system to be linked to an information management system. Create specific software functions, subject or topics and activities which can be merged with functional and administrative organizational records. Implement merged document software and train organizational staff on its use. Create specific record/document software based on business classification to convert paper and electronic files. Promote policies, procedures and records management tools to support the above software in an organization. 5.2 Inputs Resources Requirements Purchase of compilation software, business classification workshops, software usage training and consultation with organizational members. Staff Resources The roles will be divided amongst the group members where core among them is that of project manager, project coordinator, information staffs, IT team and special project staff. Milestones This has specific date of commencement and cessation, roughly a period of 6 month for any document management software. The period and task would include: 1 month for compilation of a management plan and a work plan. This will involve interviews regarding the current/ existing records keeping. 1 month for preliminary investigation for organization operations based on its structure, business needs socio-political and regulatory environments of operations which involve record keeping systems. This will provide contextual factors to influence the creation and maintenance of records. 1 month to check stage 1, analyse business activity and revision of stage 1. 1 month compilation of draft document software and check its performance 1 month Consultation, compilation of whole record keeping and completion. 1 month to revise the processes, seek authorisation and finalise the project. 5.3 Outputs The general benefits include: The software covers the totality of organization change as the new software impact on organizational personnel, changed procedures, relationship with customers and accommodating changes (Basu, Dickhaut, Hecht, Towry & Waymire 2009). Created tools will improve capability of organization to create, capture and access the relevant information to facilitate effective and efficient program delivery, decision making and policy formation Streamline the organizational processes by lining them to record keeping needs. Improve organization capacity in explaining and provision of evidence based actions and decisions when required. This is through fast and efficient access and retrieval to records facilitate document sharing, consistency and control and decrease record costs. Identify the main strengths and weakness of organizational records keeping. Define critical responsibilities of document systems and records keeping. This is through integration of electronic records with business systems, technologies and application. Promote later development of recordkeeping requirements through continuous developed system. 5.4 Tools Complete graphic and image processors, image and data manipulation system. Various editors such as graphic editor and JavaScript generator Platform to produce and deliver basic and commonly used features like Microsoft Windows (OS), workstations graphics and delivery services. A platform with arranged timeline event sequences and key symbols to show organizational core undertakings Developed flash animation which can be used to catch the organizational training, operations and advertisements needs Software compatible and able to sense various monitors, disk drives, VGA card and scanners. 5.5 Measurements Measurement in project is an important aspect which promotes project coordination, processes alignment with business case. This ensures that justification does not disappears after the project is initiated, underway or after completion (Bannerman 2008). This will involve: Measurement of claimed benefits against those of the current situation recorded, effective comparison at post-project review Measurement of the progress status to line with the primary plan Measurement of quality statistics and estimations Measurements of effort required in creating various software products Quality measurements applied to inspect the finished software product Describe the suitable timing to measure the benefits with their reasons Conclusion A new software system of information management system can be developed so as to integrate data from access databases as a core data technology infrastructure which will then support organization functional requirements. It is good to note that this project will only be done with a real or generalized organization. One of the identified areas of software operation would include transport operations, small and medium-sized enterprises or even vast organizational operations. The project would best be carried well with specific organization. However, the processes in most cases are similar and can be generalized. Challenges exist particularly when it comes to best practices management. The complete way to deal with such is organization participation in plan, implementation and training the end users. References Adam, T 2008, Sampson, process-oriented patterns for concurrent software engineering. Kent: The University of Kent, 2008. Bannerman, P. L 2008, Risk and risk management in software projects: A reassessment, Journal of Systems and Software, 81(12), 2118-2133. Basu, S., Dickhaut, J., Hecht, G., Towry, K., & Waymire, G 2009, Recordkeeping alters economic history by promoting reciprocity, Proceedings of the National Academy of Sciences, 106(4), 1009-1014. Chakraborty, Abhijit, et al. "The Role of Requirement Engineering in Software Development Life Cycle." Journal of Emerging Trends in Computing and Information Sciences 3. CMMI Institute 2013, ‘CMMI is Results’ Retrieved 2013, March 4 from http://cmmiinstitute.com/. Damian, Daniela E. Herlea. "Challenges in requirements engineering." Computer Science Technical Report (2000). Kavanagh, M. J., & Thite, M 2008, Human resource information systems: Basics, applications, and future directions, Sage Publications, Incorporated. Mike Perks, Best practices for software development projects, IBM, 2006. Miller, S 2000, Best Practices for Software Projects - Requirements Scrubbing, pragmatic software newsletters. Redding, G. M 2008, Transforming Object-oriented Models to Process-oriented Models. Brisbane: Queensland University of Technology. Sohail, A., & Umar, M 2010, Requirement engineering challenges in development of software applications and selection of customer-off-the-shelf (COTS) components, International Journal Software Engineering 1, Volume 1, pages; 32. Trace, C. B 2002, What is recorded is never simply ‘what happened’: record keeping in modern organizational culture, Archival Science, 2(1-2), 137-159. Appendices Fig 1.0: Software projects: A reassessment; Adopted from (Bannerman (2008). Fig.2.0: Project Implementation Processes; Adopted from Bannerman (2008). Read More