Requirements analysis – sure, but how?

Hard core diagrams are for geeks

… not only, but let’s admit, it takes a lot of skills to read and understand them correctly

Working software is the best way to discover requirements?

  • Ok, but it’s very expensive way and hides complex processes along the way.
  • The project’snature is iterative, but budget has its limits.
  • It would be great to spend it on more value added features than use it as a means to discover user needs and rewrite code over and over again.

Yellow post-it notes are OK

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.


How to combine flexibility with predictability?

Altkom Agile Analysis 2.0

Solution overview

Our solution: Altkom Agile Analysis 2.0 – more than the best of two worlds

Paraphrasing the founding fathers of Agile movement: documentation is not more important than conversation but still, it is crucial, especially in medium and large projects.

So it has to be done very well in order to reach a consensus among all parties about the requirements and proposed software solution.

What you get

Requirements Specification and Solution Architecture structures all information gathered, elaborated and verified during all workshops. Thanks to many workshops particular elements of final document are already commonly discussed, agreed, illustrated with examples and validated using key design concepts. Acceptance workshops require recalling of workshops outcomes instead of browsing through hundreds of pages of brand new information.

Requirements Specification and Solution Architectureby default includes:

  • goal and context
  • glossary of terms
  • business process scenarios
  • key screen navigations
  • functional requirements
  • non-functional requirements
  • key architectural concepts and assumptions

How it works

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.

Sales Process

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:

Sales Opportunity

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.

UI sketches
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.


AAA 2.0 approach benefits

  • Iterations on examples and user stories instead of very costly iterations on developed software (as in SCRUM, for example, where re-coding, re-testing and re-deployment is necessary)
  • Clear presentation of requirements, goals and proposed functional solutions with architectural concepts in one place instead of traditional separation of business requirements from software specification and design
  • Clear acceptance criteria – examples provide easy way of checking whether system behaves according to requirements
  • Less changes in source code during development thanks to better expectations’ understanding
  • Mitigation of technological risks thanks to active work of software architect in Requirements analysis
  • Requirements analysis deliverables can be used for quality assurance thanks to precise examples of system’s behavior

Contact us


Chłodna Street 51, 00-867 Warsaw, Poland

Phone: (+48) 22 460 99 31