Requirements Analysis in the Field of Software Engineering - Term Paper Example

Requirements Analysis in the field of Software Engineering Student name Institution of affiliation Name of the instructor Table of Contents 1.0.Introduction 3 1.1.Characteristics of good requirements 3 1.2.Processes of requirements analysis 5 2.0.Types of requirement analysis 5 2.1.Customer or operator requirements 5 2.2.Functional requirements 6 2.3.Performance requirements 6 2.4.Design requirements 6 2.5.Derived requirements and allocated requirements 7 3.0.Roadmap to requirement analysis process 7 3.1.Customer requirements identification 7 3.1.1.Data flow diagrams 7 3.1.2.State transition diagram 9 3.1.3.Differentiation between state diagrams and data flow diagrams 10 3.1.4.User interface 10 3.2.Developer requirements identification 11 3.2.1.Organizing developer requirements 11 3.2.2.Testability of requirement 12 4.0.Inputs to requirements analysis 12 5.0.Views of requirement analysis outputs 12 5.1.Operational view 13 5.2.Functional view of system requirements outputs 13 5.3.Physical view of requirement analysis output 13 6.0.Object Oriented Analysis and Design approach to requirements analysis 14 6.1.Object oriented design for business processes 14 6.2.Delegation of roles and collaboration 15 6.3.Role of integrated teams 15 7.0.Conclusion 16 Bibliography 17 Requirements Analysis in the Field of Software Engineering 1.0. Introduction During software development, the analysis of software requirement revolves around understanding customer needs and documenting them. At this point, the software developer is expected to express what is to be built and not how it is to be built1. As a developer, it is essential to balance between formal expressions of customer needs and wants with the language well understood by the client. The documentation of the customers’ needs has to be done to ensure that the developer has a contract between them and the customer; source of test plans; and specifies project goals and plan development cycles and increments. Good system requirements must be characterized by several elements. 1.1. Characteristics of good requirements First, good requirements must be achievable. As a developer, one has to ensure that both the functional and non-functional requirements collected from the customer are clearly expressed in a language that derives them as deliverable no matter what. This is possible by ensuring that all requirements gathered from the user reflect a certain need or meet a certain objective that has been expressed by the customer and whose solution has an affordable cost. Secondly, requirements must be verifiable. This implies that all requirements must be definable in a manner that does not display words like excessive, resistant, sufficient or other unquantifiable or undeliverable terms. On the contrary, the expected performance of the system must be expressed in such a way that the objective is quantitatively verifiable. Further, the requirements of systems must be such that the identification of system requirement must focus on achieving requirements that are not ambiguous. The implication here is that the requirements must not have more than one intended or unintended meaning. Grady reveals that the possibility is by ensuring that the right words are obtained from the client and the right language is used to define and document any of the expected system deliverables2. Fourthly, a system developer must ensure that the process of system requirement analysis is focussed on complete requirements or objective from the operator customer. Completeness is essential in ensuring that the mission profiles, maintenance and operational concepts, constraints and utilization environments are expressed using the right information and that the intended customer needs are there. Additionally, system requirements must be expressed in a terms of the need and not the solution. In most cases, system users tend to explain to the developer the kind of system they need to meet their needs effectively and efficiently. However, the system developer must ensure that the customer needs are documented in terms of the solution they need. In order to achieve this end, the developer must ensure that the system requirement addresses why and not what the customer needs not how the customer needs to meet their need. Since any system has numerous requirements like functional, derived, and retrieved amongst others, the system developer must ensure that each requirement is consistent with all other system requirements. Consistency is crucial since it ensures that there are no conflicts and that any possible conflicts are resolved prior to system design3. This way, the developer saves lots of time and money and manages to work within the required timeframe. Finally, since all system requirements are intended for a given stage of the system development, each requirement must be such that it is within the appropriate hierarchy level. In this regard, Abelein, Sharp, and Paech highlight that the system developer must ensure that each requirement is defined within the development level where it is to be deployed. For instance, design requirements cannot be deployed at the first requirements prior to obtaining customer requirements4. Additionally, the detailed requirements that relate to components would not in any case be within the system specification level. It is important for the designer to understand that misunderstanding system requirements could be as a result of developer’s bias or the bias arising from the client. Additionally, Abelein, Sharp, and Paech reveal that the developer must ensure that the client’s intended system is not expressed based on how its inner workings should be but with respect to the environment within which it is to be used and the objectives it is expected to accomplish during the course of use5. 1.2. Processes of requirements analysis The two forms of requirement analysis processes are unified process and Object Oriented Analysis and Design. The discussion in this paper will focus on system requirement analysis in the approach of OO analysis and design. 2.0. Types of requirement analysis There are several ways of classifying customer requirements and each must be related to technical management 2.1. Customer or operator requirements These are the facts or statements that represent the client’s system expectations. The expectations are classified in terms of environment, constraints, mission objectives, and suitability and effectiveness measures6. These requirements include operational deployment or distribution; related or performance parameters; mission scenario; utilization environments; effectiveness requirements; environment; and operational lifecycle. The customer or operator needs are on the minimum expected to answer questions like what use will the system serve? How will the chief objectives be achieved using the system? What parameters would be considered as critical to the system? What are the functions of various system elements? These and other system related questions will be used by the customer to emphasize that the operator or end user of the system is the most important customer. 2.2. Functional requirements Represent the actions that must be accomplished and usually refer to requirements of what has been done and are essential for top-level functional analysis. The functional requirements are a representation of what the new system has to achieve once it’s completed, tested and installed for customer use. In this regard, the functional requirements describe the real system inputs as well as the expected system outputs. Since input is in the form of data, functional requirements must state the nature of the data to be managed by the new system. 2.3. Performance requirements Performance requirements define the extent of mission execution quantified in terms of quality, quantity, readiness, timeliness, and coverage7. Requirement analysis calls for interactive development of performance requirements has to be done across all functions identified and founded on factors of system lifecycle; and characterized on the extent of certainty in estimates and system success criticality, and requirements’ associations. 2.4. Design requirements This involves the evaluation of the “code to” system requirements and the manner in which they are executed for the processes defined in technical manuals. 2.5. Derived requirements and allocated requirements These are requirements arising from higher-level –requirement. Conversely, established by dividing or allocating a higher-level requirement into multiple-level requirements 3.0. Roadmap to requirement analysis process 3.1. Customer requirements identification Zhang, et al recommends that during customer requirement identification, it is essential that one uses cases that the client individually expressed especially through a case diagram8. Additionally, the developer has to use dataflow diagrams to assist in explaining how data flows across various functions9. State transition diagrams are also used to explain how the system changes from one state as it responds to one or more operations. Finally, the developer has to include a User interface to guide them on what is expected of the system. 3.1.1. Data flow diagrams During this phase, Zhang et. al highlight that the data flow diagrams best serves the purpose of documenting the user requirements in a comprehensive and precise way. With data flow diagrams, the developer best explains how data flows across numerous functions through detailed graphic network of symbol10. The graphic network symbols represent different aspects including data stores, data sources, data processes, data destination, and data flows. To the developer, data flow diagrams are significant in that they serve as a semantic link between the developers and the operators or users. Using data flow diagrams makes it possible for the developer to avoid a thousand words; and make use of logical representations to mould the system functions and not focus on the system’s physical representation by showing what the system does. Additionally, data flow diagrams are hierarchical in that they represent any level of the system in details and in an understandable language that facilitates review by avoiding jargons. Ejnioui, Carlos and Luis require that much emphasis is placed on data flow diagrams given the aim that the developer wants to represent the system in a single model using structured system analysis11 in requirements analysis. In this case, data flow diagrams are supported by other techniques of structured system analysis like data dictionaries, data structure diagrams and methodologies of procedure-representing. Common methodologies of procedure representing include decision trees, structured language, and decision tables. Representing the customer system requirements through data flow diagrams benefits the developer from costs that may arise from developer and user system misunderstandings that may require that a completed system be redone or that the customer does not use the system. Additionally, the developer evades cost that may result from not documenting the customer system physical requirements from the start considering that even after system technological requirements change, the intended function of the system or what the system had to do remains constant. Through data flow diagrams, the developer is spared from costs that may result from inconsistencies in the system especially given that systems have to be computerized prior to their systemization. Finally, data flow diagrams avoid unforeseen costs as a result of failure to define project boundaries on time hence resulting to inappropriate scope for the project. Project boundaries are also defined as the degree of project automation. 3.1.2. State transition diagram State transition diagrams are common aspects used in object oriented or OO modelling as revealed by Abelein, Sharpand Paech12. The assumption behind the use of state transition diagrams is that the system under development comprises of infinite number of states or cases. During customer requirement analysis, the developer is expected to express collections of related scenarios using cases through the use of a case diagram. State or case transition diagrams consider that, the system is expected to receive inputs from external environment through the user, and that such events could result to responsible to system transition from one state to the next. According to Abelein, U, H Sharp, and B Paech, the key role of state transition diagrams during the collection of customer requirements is that they explain the flow of data through different functions13. That is, state transition diagrams are essential in that they offer the developer a formal or explicit description of the system’s behaviour hence requiring that one clearly defines all the system functions and behaviours. From state transition diagrams, the developer also gets to analyse and represent the behaviour of a system as a sequence of events that have the possibility of occurring in one or more probable states. In OO modelling, the developer must ensure that each of the state diagrams represents a single class consisting of all its objects and their behaviours such that it is possible to track them through the system. The two mostly used state transition diagrams by developers are harel state chart and the directed graph. 3.1.3. Differentiation between state diagrams and data flow diagrams Each developer has to be careful not to use data flow diagrams and state diagrams interchangeably. Each of these two diagrams serves a different purpose within customer requirements analysis and should not be substituted for the other14. With data flow diagrams, each of the nodes represents a command for the program and the command is the executable action which is not a program state. Conversely, state transition diagrams use explicit events to stimulate the system to perform a given function. This means that the state diagrams require no transition from one node to the next to complete its actions. 3.1.4. User interface Grady reveals that although the user interface in not a typical part of the user requirements analysis, it is important for the developer to come up with an anticipated user interface such that the requirements of the user can be visible from the perspective of the design requirements15. The design requirements analysis should be consistent with the user interface and any changes to the interface during design must be consistent with the user requirements. User interfaces demonstrate the kind of interaction expected between the client and the system and has to be designed in the simplest and most user friendly way possible. Best practices for user interface design recommend that the design facilitates the completion of the current task without unexpected attention diversion to self. In OO modelling, the user design could be such that it promotes its usability by influencing the manner in which the user executes specific interactions. Additionally, system user interface could be designed such that it enhances design aesthetics. 3.2. Developer requirements identification Additionally, the developer has to ensure that all necessary design or developer requirements are organized to identify functional and non-functional requirements, and reliability. Further, sequence diagrams should be created for outlining test plans, inspection, and obtaining requirements from customers defined needs and changing needs16. The developer has also validated with customer to ensure that the customer really understands what they want; the customer’s timelines are reasonable; and any changes in the customer needs in the course of system development. In the overall, the developer’s requirements must be testable, traceable, and time bound. Developer requirements are also expected to demonstrate completeness, and accommodate error conditions by stating how the system should behave. Although, there are different forms of system requirements, the developer must ensure that they are all consistent. 3.2.1. Organizing developer requirements During developer requirements analysis, it is crucial to identify functional requirements none functional requirements, reliability, constraints like timing and accuracy, and user interface requirements. Functional requirements must include the way in which the system will work with the inputs and how the outputs will be given back to the user. For instance, a system’s functional requirements may be to monitor changes in kiln temperature and display it on a control computer screen. The non-functional requirements revolve around the performance of the system and include the time span between temperature monitoring until the output is displayed. Reliability must be defined in such a way that the system failure probability must be within a commendable range of successful system monitoring events. Grady recommends that when organizing developer requirements, interface requirements must demonstrate that the user can easily interact with the system and other related applications17. For instance, the developer must demonstrate that the user can perform additional actions with the displayed results like print, share, or save. The developer must also not forget to leave room for constraints like error in accuracy or timing. 3.2.2. Testability of requirement The developer has to ensure that each of the requirements by the customer can be tested like through prioritization and categorization. Prioritizing each user case involves testing the strategy through sampling only the cases that are the chief architecture; critical to business success; and that have the highest risk. 4.0. Inputs to requirements analysis The most basic input in any system requirement analysis is customer’s and objectives, missions and environment or MOE/MOS, technology base, KPPs or Key performance parameters, program decision requirements, Output requirements from previous applications, and sustainability as listed by Grady18. However, there has to be comprehensiveness in the input requirements and input definitions for both system products and processes. The main categories of requirement analysis are controls, enablers, and inputs from previous systems transformed into outputs. 5.0. Views of requirement analysis outputs The three main outputs of requirement analysis are operational view, functional view, and Physical view19. 5.1. Operational view This is concerned with the way the system serves its users and is best served during the establishment of requirements of the suitable circumstances and how effectively the system has to meet the needs of the user. During requirements documentation, the operational perspective must be recorded in the concept that recognizes the definition of operational needs, analysis of system mission, sequences of operation, event for the system to respond to, and user and maintainer rules. During system requirement analysis, the identification of the system life cycle and operational needs and constraints is best done through operational view 5.2. Functional view of system requirements outputs The functional requirements part of the system is concerned with what the system intend s to do so as to yield a given operational behaviour. This perspective includes outputs, inputs, transformation rules and states needed for a given functional behaviour. The documented functional view requirements are: system performance in terms of qualitative, quantitative, and timelines; system functions; relationship between functions; constraints on performance; functional associations between hardware and software and the uniqueness of each among others. 5.3. Physical view of requirement analysis output This is the perspective of the system that concentrates on how the system is developed and forms the basis for system’s physical interfaces amongst infrastructure and operator, and the requirements driven by technology. Abelein, Sharp and Paech highlight that information of the physical output perspective must include but not limited to: the nature of configuring the system like the descriptions of interfaces controls for operators, and attributes of information display, system and operator relationships, and the skill level of the operator20. Other elements of the physical view include user characterization and system physical limitations. In user characterization, the major considerations are constraints and handicaps or identified and probable special operating environments. Additionally, constraints concentrate on the visual limitations. Conversely, the physical perspectives of outcomes must consider physical limitations like power, size, capacity, weight; technological constraints like range, frequency, language, data rates, and precision; and other necessary and directed standards. The physical perspective of requirement analysis outputs also concentrates on the government Furnished Equipment or GFE, reusability requirement and Commercial Off-the-Shelf Equipment or COTS. 6.0. Object Oriented Analysis and Design approach to requirements analysis According to Zhang et. al defines analysis as involving identification of a problem or need while design is the conceptual solution that explains how the system executes needs21. Object oriented analysis involves consideration of a problem domain through the viewpoint of objects, concepts or real world things while object oriented design involves defining a solution to a need in form of a set of software objects through virtual allocation of responsibilities to objects. Some common examples of object oriented analysis involve library systems with concepts like library, books, and journals amongst others. Through OO design, a system is defined with more emphasis on the software objects where the objects are implemented through a program. 6.1. Object oriented design for business processes When considering the use object oriented programming in business processes, the developer must first consider what the system is expected to do. For instance, in the case of a library system the system must loan and receive books, track books due dates and initiate fines on late books, and buy new books. The developer must then ensure that the system is represented in textual narrations that use cases. 6.2. Delegation of roles and collaboration During system development, organizations must identify people who will work with the developer to offer requirements for the specified business processes. In this case, the process involved is referred to as domain analysis. Through such collaboration, it is expected that class diagrams are used to expresses the OO terms in object oriented design, and responsibility assigning for various software objects. In other words, collaboration between the developer and the business team focus on defining use cases, definition of conceptual models, definition of collaboration diagrams, and the design of class diagrams. In this case, use cases are narrative characterizations of domain procedures in a prearranged prose format. With the use cases, OO analysis is concerned with problem domain specification and identification of objects while problem domain includes objects identification that includes attributes and associations. The outcome is then expressed in domain model. Conversely, the collaboration diagram uses OO design to define the fulfilment of system requirements by defining a logical software specification. Since collaboration diagrams are expected to demonstrate the flow of messages between objects, and then all objects must have responsibilities and association s showing how they link with each other done through class diagrams. 6.3. Role of integrated teams Software systems comprises of operator customers who are experienced in the developed product operational employment, and developers who most often have no expertise in the operational aspects of the system under development. In this case, it is impossible to attain a well-developed problem from which the system specifications can be developed and this calls for teamwork. Conversely, most customers tend to define systems that attempt to solve their needs and not the problem itself and this means that the developer has to come up with a workable solution that best suites the customer. 7.0. Conclusion This paper has explored the issue of software development requirement analysis process from identification of the types of requirement analysis for an effective system to the implementation of OO approach to requirement analysis. It is evident that the user and the developer have to work in collaboration to identify the processes or system requirements that optimally meets the needs of the business. Developers must be in a position to integrate customer system into real world software systems that interact with users to provide business expected services. Bibliography Read More