Week 6 - Look, Ask, Learn Try
When we develop new technology-based products or services, the actual development begins with a software requirement specification. This SRS can be created by a third person not being involved in the actual process (e.g. the business analyst), who develops, together with the user and the designer, this paper with the function of project briefing. Herein included points are: scope, purpose, functional and non-functional requirements and other software and software architecture related informations the developer might need in order to understand the nature of that software. A good SRS stands out with requirements that solely focus on the technical and functional and not on the interface and design aspects.
Generally, a SRS can contain many functionalities that may never be developed but initially had the potential to be developed. As software and IT-related it may sound, the creation of this SRS is in fact part of human-centered-design. The developer needs to understand the needs of the user, evaluate what is possible, functional and what is not. Mostly, as budget allocation and project management occur to be important in projects with bigger scope, the business analyst serves as the intermediate to understand the user, create the SRS and brief the developer/designer. It is crucial that the developer (via the business analyst) and the user have a common understanding of the outcome and the job-to-be-done by that software. However, different than a business briefing, for software requirement specs, iterative approaches and revalidating are important.
As explained in earlier blogs, the user is not always the best facilitator to understand the user's needs as some of them, he doesn't know himself yet or fails to express and articulate them. But how can we find the requirements, if the user himself might not know? User Centered Software Design Methods or Agile Software Development.
Agile Methodologies rely on the principle of continuous iteration of developing and testing
The credo is: experiment and validate with real world usage.
This software development lifecycle relies on the research method and process of : "look, ask, learn, try."
This software development lifecycle relies on the research method and process of : "look, ask, learn, try."
The most popular agile methodologies include Extreme Programming (XP), Scrum, Crystal, Dynamic Systems Development Method (DSDM), Lean Development, and Feature-Driven Development (FDD).
Towards the end of class, we then had a go in groups at estimating user stories through poker planning. The units we used were hours, as we estimated how long it would take to build a bridge out of spaghetti and tape. Our estimates were never the same, we failed to agree on any one point, and some of us changed our cards to conform to the group more so than out of desire. Please see the pictures below in relation to our user estimations.



0 comments:
Post a Comment