Assignment 2: Requirements

 

 

 

 

 

 

 

 

 

 

 

Assignment 2: Requirements

Amare Alemu

Strayer University

CIS 518 Advanced Software Engineering

Professor Christopher Barrett, Ph.D.

October 28, 2019

 

 

 

 

 

 

 

 

 

 

Assignment 2: Requirements (R)

Introduction

            This paper will discuss about R. It will firstly, select a requirement specification technique that would use to statе the requiremеnts of this software system, and explain the reasons for the selеction. Secondly, it will specify the requirements for registering a student for a class based on the selected technique. Next, it will create the necessary diagrams through the use of graphical tools in Microsoft Visio that illustrates and complements the specification. Further, it will write a validation and verification plan to validate and verify the requirement. Lastly, it will providе a summary of the topics mentioned above.

The multiview specification in UML is among the multiple types of diagrams standardized in the UML, several are relevant to the RE process: a, Class diagrams provide a structural, entity-relationship view of the system. b, Use case diagrams are used for outlining an operational view. c, Sequence diagrams complement such a view through interaction scenarios. d, State diagrams provide a behavioral view through state charts generalizing the event traces in scenarios (Lamsweerde, 2009). Further, the author discussed that the using of global predefined statement templates might help present various types of statements in a standardized form and for managing their traceability. A statement template provides named fields such as the following: 1, Statement identifier for unique reference throughout the RD; it might be a suggestive name or a hierarchically numbered identifier to express the decomposition of statement. Statement category, to make it clear whether the statement is a functional requirement, a quality requirement, an assumption, a domain property, a definition, a scenario and so forth.3, Specification of the statement itself, written according to the preceding stylistic rules.4, Fit criterion according to which analysts, developers, testers, and users can determine whether the statement is satisfactorily satisfied in the system-to-be.5, Source from which the statement was elicited (e.g., a stakeholder or report), for statement traceability. 6, Rationale of the statement, for better understanding and traceability. 7, Positive or negative interaction with other statements. 8, Priority level, for comparison with other statements and prioritization. 9, Stability and or commonality levels, for change management. Complementing some statements with a fit criterion ensures that they are measurable. The importance of making requirements, assumptions and domain properties measurable was introduced. A fit criterion associated with a statement quantifies the extent to which this statement must be satisfied. It is often associated with non-functional requirements but can complement other types of statements as well. A fit criterion can be used for assessing alternative options against it, and for checking whether the associated statement is adequately satisfied by the implementation. Templates may also be used for imposing a standard structure on RDs. It shows a well-known example of such a template (IEEE, 1998).

An ER notation is often used by more sophisticated approaches. For example, the Unified Modeling Language (UML) is a collection of notations used to document software specifications and designs. We will use UML extensively to describe object-oriented specifications and designs. Because UML was initially conceived for object-oriented systems, it represents systems in terms of objects and methods. Objects are akin to entities; they are organized in classes that have an inheritance hierarchy. Each object provides methods that perform actions on the object’s variables. As objects execute, they send messages to invoke each other’s methods, acknowledge actions, and transmit data. The flagship model in any UML specification is the class diagram, a sophisticated ER diagram relating the classes (entities) in the specification. Although most UML texts treat class diagrams primarily as a design notation, it is possible and convenient to use UML class diagrams as a conceptual modeling notation, in which classes represent real-world entities in the problem to be modeled. It may be that a class in the conceptual model, such as a Customer class, corresponds to a programming class in the implementation, such as a CustomerRecord, but this need not always be the case. It is the software designer’s task to take a class-diagram specification and construct a suitable design model of the implementation’s class structure. In general, the kinds of real-world entities that we would want to represent in a class diagram include actors (e.g., patrons, operators, personnel); complex data to be stored, analyzed, transformed, or displayed; or records of transient events (e.g., business transactions, phone conversations). The entities in registration problems include people, like the students and administrators; the items in the registration, like student file and administration decision files; and the receipts, (Phleeger, 2009). Based on the selected technique, the student’s registration requirements will be specified as follows. It should have student name (first name, middle name, and last name), student ID, student gender, student email, student address, student phone, list of classes, etc. (JotForm, n.d.).

Regarding the creation of a diagram, the MS Visio is utilized diagram 1 below for the illustration that complements the following hypothetical specification.

Diagram 1 The Specification Complement

 

In requirements validation, we check that our requirements definition accurately reflects the customer’s—actually, all of the stakeholders’—needs. Validation is tricky because there are only a few documents that we can use as the basis for arguing that the requirements definitions are correct. In verification, we check that one document or artifact conforms to another. Thus, we verify that our code conforms to our design, and that our design conforms to our requirements specification; at the requirements level, we confirm that our requirements specification conforms to the requirements definition. To summarize, verification ensures that we build the system right, whereas validation ensures that we make the right system (Phleeger, 2009). Further, validation is the procеss of confirming the completеness and correctness of requiremеnts.  Validation also ensures that the requiremеnts: 1) achieve stated businеss objectives, 2) meet the needs of stakеholders, and 3) are clear and understood by the devеlopers. Validation is essential to idеntification of missing requirеments and to ensure that the requirеments meet specific quality characteristics.  Validation addrеsses each individual requirеment to ensure that it is: Correct (accurately states a customer or external need), Clear (has only one possible meaning), Fеasible (can be implemented within known constraints), Modifiablе (can be easily changed, with history, when necessary), Necеssary (documents something customers really need), Prioritizеd (ranked as to importance of inclusion in product), Tracеable (can be linked to systеm requirеments, and to designs, code, and tests), Vеrifiable (correct implеmentation can be determined by testing, inspection, analysis, or dеmonstration). Vеrification is the process of confirming that the designed and built product fully addresses documented requirements.  Verification consists of performing various inspections, tests, and analyses throughout the product lifecycle to ensure that the design, iterations, and the finished product fully addresses the requirements. To prevent rework, requirements should be validated and approved before design. If the requirements are not confirmed, then requirement validation and product verification will inevitably be done together during product design and development activities. Because verification is guided by requirements, there is high likelihood that missing or invalid requirements will not.  Missing and invalid requirements causes rework and significant cost overruns (Parker, 2011).

                                                Conclusion

The paper selected a requirement specification technique that would be used to state the requirements of this software system and explained the reasons for the selection. Secondly, it specified the requirements for registering a student for a class based on the selected technique. Next, it created the necessary diagrams using graphical tools in Microsoft Visio that illustrates and complements the specification. Further, it did write a validation and verification plan to validate and verify the requirement.

References

JotForm (n.d.). Class Registration. Retrieved on October 22, 2019

            from http://bit.ly/31JtR3F

Lamsweerde, A. (2009). Requirements Engineering: From System Goals to UML

Models to Software Specifications [VitalSource Bookshelf version, pp. 123-124, 144].

Parker, J. (2011). Rs Verification and Validation. Retrieved on October 22, 2019

            from http://bit.ly/32Tv4qs

Phleeger, S. L., Atlee, J. M.  (2009). Software Engineering: Theory and Practice, 4th Edition

            [VitalSource Bookshelf version, p. 159, 198-199].