Individual Critical Reflection Report The WritePass Journal

Individual Critical Reflection Report Abstract Individual Critical Reflection Report , p40) claims that the system requirements model entails what the system in its entirety is required to do. It may be broad and high level or more specialized and detailed depending on the type of processes in question. The group chose the detailed requirement because it allows for organization into hierarchy that culminates into highly efficient processes.  Ã‚   This was important because it helped the group meet high level requirements in the design and functioning of the process. In so doing the group was able to manage the complexity of large systems although we found it necessary to be more careful while moving to the design/ analysis model e in order to minimize on errors. The group realized that the systems requirements model had a few shortcomings like it at times fails to meet the requirements of the user and this may go undetected   until the system is integrated, when this happens, it leads to unnecessary inconveniences in terms of both time and resources. Additionally, the model has a relatively longer than the desired development cycles. The fact that requirements change so quickly with advancements in technology and other related factors often render the systems requirement model unsuitable because of the high costs incurred during upgrades for the system to meet the new requirements (International Workshop IW-SAPF-3, Linden, 2001, p53 Satzinger, Jackson, Burd, 2008, p59). It was always challenging to decide when to transit to the design/ analysis model owing to the various shortcomings that are encountered at the requirements model level. The analysis / design model Casteleyn (2009, p43) asserts that the objective of any model is to support the efforts of the architect in making the project to have the right design, specification and decisions in order to achieve the intended goals.   The right design and specification is often assessed using denominators like business viability, customer satisfaction, meeting the constraints of the project and the associated risk levels. For the designer to be able to meet the required standards, he or she needs to work with sufficient credibility, accuracy and working range. In essence the analysis/ design model is an improvement on the requirements model as it relies on it in generating information like customer preferences, market trends and the industrial characteristics.   Once the requirements stage is well orchestrated, then the analysis/ design model will be more efficient owing to the reduction in errors (Wasson 2005, p89).   The reverse is also true as inefficiencies in design leads to errors be ing carried forward to the analysis/ design stage. Issues and limitations A good model should be able to detect any defects early in the life cycle of a product. As such testing should be carried out as early as possible in order to minimise the costs of repair. This implies that testing should be integrated in the design of the system so that it can be verified against the requirements as early as possible. This is the basis on which the requirements model works as it understands and outlines the set of requirements in advance. As earlier outlined, the main reason behind modelling is to contribute to easy identification of any incompleteness and ambiguity in the input material. The requirements model often assumes that the textual requirements provided as input in the process often adhere to very high quality standards, although this is not always the case as evidenced by the defects that often arise later in the process. This is in fact where the design/ analysis models steps in as it enables the requirements analyst to improve quality by further modelli ng the requirements in a formal representation as this allows for a detailed analysis of such requirements (Slooten, ebrary, Inc. 2002, p32).   The reliance of the analysis / design model on the requirements is very evident and critical as it reuses the requirements for the verification of the various available alternative designs. This ensures that the final product is greatly improved because the errors and any other mishaps are fixed in time (Information Resources Management Association 2011, p67 IFIP WG 8.1 et al 2007, p77). One of the biggest issues that faced the group and is also a challenge to the other software developers is knowing when and how to transit from the requirements stage to the actual design/analysis stage. This was a major point of contention as some members felt that we were transiting too early while others felt that it was the right time to make the transition. The challenge here is to make the right call because an incorrect one can be very costly in terms of both time and resources. An early leap puts the whole project on the precipice of collapse because of the sketchy requirements whereas a late leap leads to postponement of high risks as they are transferred to the later stages of the project lifecycle. Possible improvements to the teams work (with regards to the specific chosen topic) One of the most important things that the group realized was that it is very important to make smooth the transition process from the requirements to design/analysis model.   It is important to have an artifact that ties directly the two workflows into one organized unit (Tari,   Corsaro,   Meersman, 2004, p72 Chiang, Siau, Hardgrave 2009, p56). The project team should make good use of case realization as the transitional artifact. This activity should occur in the first recapitulation of the elaboration phase. The use case realization acts as a transitional element that specifies how the use case will be implemented in the final project. However, it is critical to note that the use case realization is indeed a composite artifact that contains other design models that are a representation of the actual realization. The collaboration diagrams and UML sequence are some of the models that the group can use as case representations.   Once the group makes good use of this then the whole process of transition will be relatively easy as it leads to efficiency of the whole process. Bibliography Casteleyn, S. (2009). Engineering Web applications. Dordrecht: Springer. Chiang, R., Siau, K., Hardgrave, B. C. (2009). Systems analysis and design: Techniques, methodologies, approaches, and architectures. Armonk, N.Y: M.E. Sharpe. IFIP WG 8.1 Working Conference on Situational Method Engineering: Fundamentals and Experiences, RalyteÃŒ , J., Brinkkemper, S., Henderson-Sellers, B. (2007). Situational method engineering: Fundamentals and experiences : proceedings of the IFIP WG 8.1 Working Conference, 12-14 September 2007, Geneva, Switzerland. New York: Springer Information Resources Management Association. (2011). Instructional design: Concepts, methodologies, tools and applications. Hershey, PA: Information Science Reference. International Workshop IW-SAPF-3, Linden, F. . (2001). Software architectures for product families: International Workshop IW-SAPF-3, Las Palmas de Gran Canaria, Sapin, March 15-17, 2000 : proceedings. Berlin: Springer. Satzinger, J. W., Jackson, R. B., Burd, S. D. (2008). Systems analysis and design in a changing world. Cambridge Mass: Course Technology. Slooten, K. ., ebrary, Inc. (2002). Optimal information modeling techniques. Hershey, PA: IRM Press. Tari, Z., Corsaro, A., Meersman, R. (2004). On the Move to Meaningful Internet Systems 2004: OTM 2004 Workshops. Berlin: Springer. Turban, B. (2013). Tool-Based requirement traceability between requirement and design artifacts. Wiesbaden: Springer Vieweg. Wasson, C. S. (2005). System Analysis, Design, and Development: Concepts, Principles, and Practices. Hoboken: John Wiley Sons.