Requirements analysis based on state-of-the-art Specification by example methodology, which is an answer for two antagonisms: traditional phased requirements analysis with detailed design and SCRUM-like methodologies.
Tell us your story
Plain text, simple “step by step” description what you do, what is the purpose of what you do and how to help you with software solution. We will structure these data into business process scenarios and functional requirements.
Show me your examples (documents, sketches, other apps)
Examplesare the key to understand the requirement and make sure what we do is in line with business goals. When there’s no example – it signals something needs to be investigated more thorough or changed. We will use examples to illustrate both glossary terms and requirements
Validate your requirements by examples
Complex calculations or structures can be presented by many means. Our experience proves, that seeing something and having the possibility to manipulate entry data with immediate impact on results is crucial to find possible mistakes or unpredicted exceptions.
Common language is the key
Glossary, created together, helps us understand terms and processes in the same way.
Set of steps aimed at initiating and supporting the identification and evaluation of likely customers (sales opportunities), sales presentation, and successful conclusion of sales activities. It requires a close coordination of people, equipment, tools, and techniques, and includes advertising and promotion. It is phased into stages:
Is a contact or an account that has been qualified. This person has entered into your buying cycle and is committed to working with you. You have already contacted, called or met him and know their needs or requirements.
Let us work together (close feedback loop)
Communicate often and openly to avoid analytical gaps and misunderstandings using variety of tools – meetings, video conferences, messaging.
Let us help you take the right decisions
In most companies, there are many parties involved, each with its own goals and needs. Sometimes they are conflicting. As experienced consultants, we know how to value their requirements and propose adequate compromise. We are objective and as an external expert we are considered as such by all involved parties in your company.
Acceptance criteria for each requirement
Help us to define the scope of the requirement and once again to make sure we all understand the requirement the same way. Common definition of “done” is also the key ingredient for future test scenarios.
Jumping too quickly to UI part of shared application design is not a good idea as it tends to avert our attention from business goals However, once we know what you’d like to achieve, we move to HOW to get there from UX perspective. We will also use sketches as design concepts visualization.
Proven feasibility by key design concepts
High-level design prepared for crucial requirements assure implementationof right solution in efficient and reliable way. Such key design concepts are described and illustrated with relevant examples (e.g. UI sketches, sample calculations). Subsequently, design concepts are discussed, explained and accepted as agreed direction for requirement implementation. We structure these design concepts together with requirements or as key architectural concepts and assumptions. We offer also ready-for-use set of standard UI elements and application behaviours to fasten requirements elicitation and elaboration.
Rest assured – everything is well documented
Analytical living documents (wiki) with glossary, user epics, user stories, UI sketches, prototypes – updated, readable, not requiring high tech skills to understand.Everybody is welcome to participate.
Everything is well organized
Analytical work should fit to your company. We can work in your methodology, we can also propose our approach to requirements analysis organization and time schedule. Altkom Agile Analysis 2.0 offers all benefits of agile approach in both agile projects and fixed-price projects.
Hard core diagrams are for geeks
… not only, but let’s admit, it takes a lot of skills to read and understand them correctly
Yes, but not precise enough – lack of precision tends to be expensive.
User stories are excellent to understand business needs, but software simply needs more information to estimate properly.
Initial understanding of “one sentence” requirements and cost of development may differ 100 times compared to the final shape of the requirement and its implementation.
Altkom Agile Analysis 2.0