2

I'm working for a large company that's currently overhauling its network infrastructure, and several departments within the company have expressed interest in APM, desiring a tool for performance monitoring and error catching, customer tracking, business transaction management and the like.

However, the organisation's size, and the fact that different interest groups wish for different features, has made it quite difficult to choose the right one between the available options. There are quite a few APM tools out there, both open source and commercial, and they seem to be boast somewhat different features, focusing on different things.

As part of my master's thesis, it's fallen to me to map out these requirements and make a recommendation based on the results. I'm somewhat familiar with requirements engineering in general from an academic perspective, but that has always been from the perspective of building a new software application, not selecting between pre-existing ones (which shoe fits the best?)

Are there any academically sound models for performing requirement elicitation and analysis under these sorts of conditions? In short, helping a customer, represented by multiple different internal interest groups, pick a specific piece of software between a plethora of available ones? Or is this something where the standard IEEE should be used as-is?

PlanB
  • 39
  • 3

2 Answers2

3

Requirement elicitation and analysis for COTS software uses similar techniques than normal software development projects (interviews, workshops, document analysis, observation, user stories, etc...).

The first major difference is how you use them:

  • For custom development, you have full creativity: you can go very deep in asking your users for their expectations and therewith design tailor made solutions.
  • With COTS you need to stay at a high level and focus on the objectives (what the software shall do, not how it shall do it).
  • For custom development you may choose your pace and your roadmap: you may for example start to gather requirements and start to design and develop the solution and gather other unrelated requirements later.
  • With COTS you need to get a full overview of all high level resuirements, because these will lead to the choice of the product, and if you have forgotten an important element, you might discover that the chosen product can’t deliver it wheareas another product could well do it.

Once you have the high level requirements, you may start to analyse, categorize and group them. You will also start to look at the features offered by the product on the market. Both activities will happen in parallel, since the market features will influence the way you group and analyse your internal requirements. It may also happen that several products address needs that were not spotted in the first place. So maybe you’ll have to make a round of complementary requirements gathering, to see if the missing features are relevant and how much.

Once you have your requirements on one side, the market capabilities on the other side, you’ll have to find the COTS which is the closest match (and in reach of your budget). For this you will need to transform your internal requirements into weighted evaluation criteria.

Keep in mind that this is not a mathematical game and that you’ll have to live with the chosen product for a long time. So maybe, instead of selecting the closest score, you use the score to make a short list and ask for demos / quotes to this short list, involving the requesting departments in the evaluation of the demos.

Pitfalls to avoid:

  • get a first small set of user stories, choose the product accordingly and start to deliver fast. This is guaranteed to fail in a COTS approach.
  • dig deeper upfront and immediately analyse all the needs in detail, without knowing what COTS can offer. This is rework guaranteed: the solution chosen cannot offer everything you want (otherwise it would be a custom development)
  • make a long (flat and unweighted) list of requirements: this will not focus on what really matters and your choice might later appear to be a poor one.
  • choose the product by best score: later, the users will make you understand that you’d better have involved them in the final choice.
Marco Borchert
  • 172
  • 1
  • 3
  • 8
Christophe
  • 74,672
  • 10
  • 115
  • 187
1

My mind come to think about something I have not used for quite a long time: the PREview(1) method which uses a viewpoint approach that seem to be appropriate for your needs.

Typically today not to be bogged down by endless requirement elicitation I would create or reuse a Capability model of APM and then do a prioritised Impact mapping where different stakeholder groups get to prioritise the features (functionality requirements) that enables different capabilities that creates the end outcomes various stakeholder groups are looking for. This methodology is a combination of Service Design(2) Double diamond(3) - Impact Mapping(4).

1) PREview method https://www.researchgate.net/publication/2400936_Viewpoints_for_Requirements_Elicitation_a_Practical_Approach

2) Service Design: https://www.interaction-design.org/literature/article/the-principles-of-service-design-thinking-building-better-services

3) Double diamond: https://www.designcouncil.org.uk/news-opinion/what-framework-innovation-design-councils-evolved-double-diamond

4) Impact Mapping https://www.impactmapping.org/

AlexanderHedlund
  • 61
  • 6