ipl-logo

Case Study: A Touch Of Grass

872 Words4 Pages

According to the coursework case study (2017), A Touch of Grass by Sarah (TOG) is a small company which was registered in 2008 by Sarah Bromley, a Glassblower who learned glassblowing from her father. The company makes glass products such as glasses, vases, ornaments, sculptures and bespoke pieces. Furthermore, the organization intends to introduce glassblowing classes and tours of the facility as a way of expanding its business because most customers are interested in the glass manufacturing process.
Currently, A Touch of Glass is overwhelmed by its customer base and demand for its products. Consequently, TOG cannot effectively manage its customers and their purchases because it uses fragmented systems to market and sell products, contact …show more content…

Therefore, DSDM Atern recommends that key users who understand business objectives should be part of a project team and assigned specific roles and responsibilities so that they work with technical members to produce a solution that focuses on business needs. In addition, these users should be able to make decisions on behalf of the business to ensure progress throughout the project so that a solution is implemented within the agreed time and budget. For example, Sarah Bromley, should be the Business Sponsor and Business Visionary because she can make strategic and financial decisions that affect the …show more content…

Therefore, stakeholders need to agree on important things to be included in a system so that a solution can be delivered within budget and on time. In DSDM Atern, requirements are categorized based on the impact they have on the delivery of the system using MOSCOW rules. The letters MOSCOW stand for Must Have, Should Have, Could Have and Won’t Have this time. Must Have requirements are critical for the final system to work. Should Have requirements are not considered time-critical requirements and can possibly be included within the delivery time frame. Could Have requirements are desirable requirements but the system can still work even if they are not included. Meanwhile, Won’t Have requirements are features which stakeholders may want to have but can be implemented in later versions of a system. For example, requirements which were submitted by TOG Staff need to be prioritized accordingly because they are not all needed for the new system to

Open Document