Vaatimusten muuttuminen sovelluskehityksen aikana : Case: Handle I.T. Oy

Abstract

On tärkeää osata varautua vaatimusten muutoksiin ja ymmärtää mitkä asiat voivat johtaa muutostarpeiden syntymiseen osatakseen varata riittävästi resursseja niitä varten. Opinnäytetyössä tarkasteltiin alkuperäisten vaatimusmäärittelyiden ja toteutuneen järjestelmän eroja sekä pohdittiin syitä muutostarpeisiin. Tarkastelun kohteena toimi aloittelevan ohjelmistokehittäjän Handle I.T Oy:lle tekemä toiminnanohjausjärjestelmä.

Vertaillessa alkuperäisiä vaatimusmäärittelyitä ja lopullista järjestelmää havaittiin, että järjestelmästä oli tullut paljon alkuperäistä suunnitelmaa monipuolisempi, eli vaatimukset olivat muuttuneet projektin aikana suuresti. Eniten muutoksia vaatimuksiin oli tullut järjestelmän kehitysvaiheessa. Järjestelmään haluttiin uusia ominaisuuksia ja osa alkuperäisistä vaatimuksista muuttui. Muutosten tarve syntyi usein kasvaneesta tietoisuudesta syntyvää järjestelmää kohtaan sekä asiakkaan että ohjelmistokehittäjän osalta, ja aiheutti projektin aikataulun venymistä.

Projektin venymistä aiheutti myös kommunikoinnin heikkous. Vaatimusmäärittelyiden tiiviit kuvaukset antoivat väärinymmärryksille tilaa ja ohjelmistokehittäjä ymmärsi välillä vaatimuksen oikein vasta keskustelun tai erillisen kuvan kautta. Suurimmat muutokset järjestelmään aiheuttivat uudet vaatimukset, joiden takia jouduttiin muuttamaan tietokantarakennetta. Todettiin projektin alkuvaiheessa tehtyihin päätöksiin liittyvien muutosten vaativan sitä enemmän resursseja mitä myöhemmässä projektin vaiheessa muutostarve havaittiin.

To be able to reserve enough resources, it is important to be prepared for changes in requirements during software development and to understand what things may cause the need to such changes. This thesis focuses on observing the differences between originally set requirements and the completed system. The thesis examines an enterprise resource planning (ERP) system created by a junior developer for a company called Handle I.T. Oy.

When comparing the original requirements specification and the completed system, it was found that the system had become much larger than anticipated, which means the requirements had changed dramatically during the project. Most of the requirement changes had emerged during the systems development phase. New features were wanted and therefore some of the original requirements changed. The need for changes was often a result of the customer’s as well as the software developer’s grown understanding of the system being developed and affected the project schedule negatively.

In addition, poor communication affected the schedule. Compact information on the requirements specification gave room for misunderstanding, and the software developer sometimes understood particular requirements only after having a conversation or receiving a descriptive image. The biggest changes to the system were afflicted by new demands that required changes to the softwares database structure. It was noticed that changes made in the early stages of the project required more resources the later the need for a change was noticed.