Customer Requirement Patterns for Software Vendors

Kousik Sankar R Engineering and R&D Services

HCL Technologies Limited SEZ, Jigani

Bangalore, India sankar.kousik@gmail.com

Aneesh Krishna Department of Computing

Faculty of Science and Engineering Curtin University

WA 6845, Perth, Australia a.krishna@curtin.edu.au

Abstract— More and more electronics companies are outsourcing their hardware/software components. With a number of mergers and acquisitions, the number of available system software vendors is decreasing. The rising complexity in product features also places tremendous burden on each vendor to manage their requirements in such a way so as to cater to diverse requirements sets from various customers. As a result, it becomes imperative to pin down the requirements as early as possible in the development phase to ensure a greater chance of project success. This paper discusses a model that is based on requirements patterns. This model comprises of various requirements sets that focus on requirement aggregation and classification thereby managing high-level requirements in an efficient manner.

Keywords-Requirements Engineering; Requirements Pattern; Software Vendors; Hybrid Methodology

I. INTRODUCTION

Large electronics companies that focus on volumes are being forced to outsource some or all of their software and hardware subsystems to remain competitive in the international market. This is true across diverse domains ranging from laptops, servers and PCs to consumer electronics products like Blu-ray Disc/DVD players, mobile phones, personal video recorders, digital cameras etc. The business model is also changing from the traditional “do-everything in-house” to “buy-n-integrate” model. As the complexity in product features increases, it becomes imperative to ensure that the requirements are clear, complete and unambiguous as early as possible [1].

Figure 1 depicts the requirements that are progressively frozen at the end of each development phase [2].

Figure 1. Percentage of Frozen Requirements.

There are various techniques available to model the

requirements ([7], [8]). Notable among them is the i* modeling framework ([9], [10]).

ISVs (Independent Software Vendors) have higher risk-taking abilities, small concentrated development teams, and focus more on software than documentation. This places the burden of communicating the right requirements on the buyer (OEM customer) and verifying / validating the requirements on the vendor. The term ‘customer’ refers to an OEM buyer throughout this paper.

The Hybrid Methodology Design approach used in agile development ([14]) works for most requirements; however, there is a challenge in deriving non-functional requirements and concurrent requirements. Given the extensive and generic research done using i*([11], [15]), it was found to be a logical choice to use i* for the customer requirements. We used the concept of soft-goal (based on the notion of satisficing [8]) and this provided a flexible and interactive style of reasoning with the customer. After interactions with a few customers, we detected both commonalities and a large number of differences in their software requirement specifications. We decided to group the common requirements into requirement classes called as “base” requirement classes. The differences in the

2013 IEEE 16th International Conference on Computational Science and Engineering

978-0-7695-5096-1/13 $31.00 © 2013 IEEE

DOI 10.1109/CSE.2013.82

508

2013 IEEE 16th International Conference on Computational Science and Engineering

978-0-7695-5096-1/13 $31.00 © 2013 IEEE

DOI 10.1109/CSE.2013.82

508

software requirements were split into base requirements and constraints. The constraints were grouped into the derived classes corresponding to the base requirement class. Figure 2 depicts this classification.

COMMON

REQ

DIFFERENT REQ

Figure 2. Base Requirement and Derived Requirement Classes.

The evolution with examples is elaborated below:

1. The Base requirement class: This is the original requirement that was thought out by the vendor during initial development. Over the course of many interactions with various customers, the base requirement may get sufficiently abstracted. For example, “The Blu-ray Disc recorder shall allow creation of virtual play-lists” is a base requirement (hereby referred to as BR1).

2. The Derived requirement classes: This class of requirement is derived from the base class by imposing one or more constraints. This constitutes the related requirements of various customers (each forming a separate class with its own attributes). For example, “The Blu-ray Disc recorder shall not impose any special restriction on the number of virtual play-lists created as long as the number of total play-lists does not exceed that specified in the Blu-ray Disc standard” is a derived requirement class (DR1_1) of the above base requirement class. “The Blu-ray Disc recorder shall not allow more than 3 virtual play-lists for each real play-list created by the user, subject to the fact that the total number of play-

lists does not exceed that specified in the Blu-ray Disc standard” is another example of a derived requirement class (DR1_2) from the same base class BR1. However DR1_1 and DR1_2 are contradictory.

Arriving at the base requirement class for each requirement set was a challenge. We used “requirement patterns” to arrive at the base and the derived requirement classes. A requirement pattern is, in short, an approach to specifying a particular type of requirement [3]. It is applied at an individual requirement level in order to guide its specification. We encountered practical issues in using i* to model the commonalities in the customer requirements.

When we attempted to specify the customer requirements, we found quite a lot of commonalities and a large number of differences in the way the customers perceived requirements. We decided to classify, at a broad-level, the customer type that the requirement belonged to. For example, Customer A wanted support for dual layer Blu-ray Disc recording that was tested for above average performance, whereas Customer B wanted only single layer Blu-ray Disc recording but tested to extremely high degrees of perfection. Customer A falls in the mass market manufacturer whereas Customer B falls in the niche manufacturer category. In this case, the Base requirement is “System shall support recording on Blu-ray Discs”. The derived requirement for Customer A would be “Support for dual layer Blu-ray Disc recording” and that for customer B would be “Support only single layer Blu-ray Disc recording”.

Classifying the requirements into base and derived requirement classes helps to a great extent in the design of the component API specifications. It also assists in design and code re-use.

We found that a large number of these requirements fell into a relatively small number of requirement types, which we call as ‘requirement patterns’. For example, we encountered a number of performance entities, such as response time limits and standby power consumption, each with its own requirement.

Given the extensive degree of commonality in requirements approaches with customers, we decided to model these requirements in a pattern-oriented style.

This paper proposes the usage of requirement patterns to guide the formulation and specification of the requirements. Used in an efficient way, it can greatly improve the quality of the requirements from the customer’s perspective. Each project can add to the customer requirement pattern class and its patterns, thereby creating a wealth of guidance in deriving customer requirements specification as depicted in Figure 3.

509509

Figure 3. Customer Requirement Specification. This paper discusses the usage of requirements

patterns to get the customer requirements right, from the vendor’s perspective (see section II). More specifically, this paper focuses on the differential aspects of the requirements wherein a base product already exists. Capturing the requirements of the base product is beyond the scope of this paper. The case under study here is the OEM market for HDD recorders. This is a fairly complex product comprising of 160/250/400 GB HDDs, a recordable optical drive, IEEE1394 port, USB 2.0 port, Digital and analog tuner, and supporting all associated multiple concurrencies like HDD recording / playback, or HDD recording / optical playback, or HDD copy / tuner playback etc.

II. CUSTOMER REQUIREMENT

PATTERN CLASS

Traditional customer management involved communicating the Functional Requirements Specifications (FRS), the User Interface requirements Specifications (UIS) if any, and rarely, a Non-Functional Requirements Specification (NFRS) ([12]). This approach used to work fine for low complexity products with low levels of concurrency use-cases. But as the complexity increases together with higher expectations of concurrencies from the end-user, just specifying the requirements in a traditional way (i.e. providing FRS/UIS/NFRS documents) to the customer and expecting the customer to understand them is inviting ambiguity and risk of project failure.

Before embarking on the pattern details, we found that dealing with customers involves a lot of technical and commercial data that tends to accumulate in a very short time. We kept the broad picture in mind (namely

the risk vs. customizability tradeoff) [13] as depicted in our software architecture blocks as shown in Figure 4.

Figure 4. Risk vs. Customizability tradeoff. Hence we propose a customer requirement pattern

that is an aggregation of many requirement patterns. These requirement patterns are composed in such a way that they retain a mapping with the traditional entities viz. FRS, UIS, and NFRS. As and when new patterns emerge during customer interactions, the customer requirement pattern class can be updated to reflect them.

The patterns depicted in Figure 3 can be either existing patterns or new patterns designed specifically for the customer requirement pattern.

We have depicted the various patterns using the template designed in [3].

The customer requirement pattern class comprises of various patterns as shown in Figure 5.

Figure 5. Customer Pattern Constituents.

Details on each of these patterns are outlined

below:-

A. User Features Pattern (UF):

In dealing with customers who already have a similar product of their own, (almost 70% to 80% of the customers come to a vendor because of this reason) this approach is very useful. For each of the user

510510

features, you set a benchmark with the customer’s own product and test whether the result is acceptable to you or not. Figure 6 depicts the template for the UF pattern.

Anatomy Details

Pattern manifestation v1.0Owning Domain Product featuresRelated Patterns None

Anticipated frequency Upto 20% of customer requirement patternsPattern classification Functional

Pattern Author Kousik Sankar

Situations where the pattern can be applied

Use this pattern in those situations where it is necessary to compare the features of the customer and the vendor side-by-side.

Situations not to use the pattern Not to be used in situations where total ROM (code-size) is quite small (~few hundred KB)

Form of requirements Ensure that the user requirements are in the same format as in xls or using same or similar requirements tools

Product hardware based classification

Specify the user features based on the product hardware components. For eg, if the product is a DVD recorder, then specify features of the tuner, the

optical drive, the video / audio encoder / decoder etc.

Ranking of importance to features

Get the customer's ranking of relative importance (on a scale of 1 to 10) given to features during development. This will help in understanding and setting priorities during maintenance/testing. It will also give an idea of the

underlying product strategy

Abstraction levelRemove the constraints from the user feature list, by comparing features between the vendor and customer, thereby abstracting the user feature to

such a level that it can be re-used across diverse customers.

Absent featuresGet the list of features that are absent in the vendor's requirements but

present in customer requirements. Analyse internally if these features add value and the cost of adding them if needed.

Present featuresGet the list of features that are present in the vendor's requirements but

absent in customer requirements. Analyse internally if these features add value and the cost of removing them if needed.

Common Feature Comparison Get a qualitative assessment of the common features by deploying a small group to compare the stability, ease-of-use and extendability.

Output ResultThe output of this user feature comparison should be a technical ranking (both qualitative and quantitative) of the customer features versus that of

the vendor's.

GeneralThis section is optional and can be used to record the requirements

engineer's views which do not fit in any of the above sub-sections. For eg the customer has plans to align with the vendor's FRS or vice-versa.

Extra Comments

User Features Pattern

Basic Details

Applicability

Content

Figure 6. User Features Pattern template.

Some of the common features that were used are

listed below: • Ability to Pause live TV and the quality of the paused

picture. • Navigation within the program (fast forward /

backward) and navigation between programs • Ability to navigate from the start of the time shift buffer

to the end (total duration of 6 hours) within 4 seconds.

B. Performance Pattern (PERF): For each performance entity in the vendor’s FRS,

test against the customer’s data and check for suitability. There is always a possibility that the customer may not have recorded such data. In that case, it is necessary to perform these tests either from the vendor’s end or the customer’s end (preferably from the vendor’s end since it improves the vendor’s “serviceability”)

There is also a possibility that the customer’s FRS may contain performance figures that are impossible to test in a reasonable amount of time. For eg. MTBF

(mean time between failures) for HDDs. We had faced a classic HDD read failure issue (with probability 1 out of 5000) out of a series of HDD read/write calls to one particular HDD vendor. The nature of this issue was that it completely hung the system, making the subsequent write call unsuccessful thereby making the existing recording completely unusable. This made the problem too severe to be ignored.

Testing the HDD with a series of read/write calls did not expose the problem, since it involved interaction with the other services also. Hence the approach adopted was to enable specific scripting within the source code to highlight the problem details and give a detailed and separate log file dump and continue normal testing. In this way, the root cause for the read failure issue was tracked down and closed with the vendor. Figure 7 depicts the template for the PERF pattern.

Anatomy Details

Pattern manifestation v1.0Owning Domain Product PerformanceRelated Patterns None

Anticipated frequency Upto 15% of customer requirement patternsPattern classification Non-Functional

Pattern Author Kousik Sankar

Situations where the pattern can be applied

Use this pattern in those situations where it is necessary to compare the performance of the customer and the vendor side-by-side. Typically, this pattern should be used

whenever the product complexity is between medium to high.Situations not to use the

patternNone

System classification Classify the software systems into similar layers both for the vendor and the customer. This will help in comparing with performance figures for similar activities.

Performance entitiesEnsure that the entities whose performance is measured are same or similar between the

customer and the vendor. These entities can be API calls, critical function blocks, feature sets or even low-level driver calls.

Product hardware details Specify the product hardware components and their respective vendors. This will help in dealing with the performance differences between various types of components.

Ranking of importance to performance entities

Get the customer's ranking of relative importance (on a scale of 1 to 10) given to the performance entities. This ranking should more or less match (though not exactly the

same) with the features ranking discussed in UF pattern. This will help in understanding and setting priorities during maintenance/testing.

Abstraction levelRemove the constraints from the performance entity list thereby abstracting the

performance requirement to such a level that it can be re-used across diverse customers.

3rd party software performance

If the customer has integrated a 3rd party software, then it may be possible that the 3rd party performance entities in the customer's stack may appear slightly superior

performance-wise compared to similar functionality done in-house (vendor's side for example). This degradation is normal and is attributed to modularization and API

formation as opposed to well-integrated and highly coupled functionality.

Output Result The output of this performance comparison should be an entity level performance comparison of customer versus that of the vendor's.

GeneralThis section is optional and can be used to record the performance engineer's qualitative

views which do not fit in any of the above sub-sections. For eg reasoning why the customer performance is better / worse than that of the vendor's.

Extra Comments

Performance Pattern

Basic Details

Applicability

Content

511511

Figure 7. Performance Pattern template.

One entity that has to be considered in this pattern is:

Crucial Feature addition: Sometimes, adding one feature can degrade performance of previously working features to such an extent that one tends to suspect that some serious driver layer bug has occurred. This happens when the system resources are being utilized to the maximum. This is pronounced especially when interacting with customers in a partnership (joint development) approach. It is important to list down and track the features that have been added together with the system architect overseeing the performance and handling the exceptions at each stage [6].

C. User Base pattern (UB): In order to successfully cater to the emotional needs

of the end-user (who ends up buying the product from the retail shelf), the next step is to compare the user base profiles and the emotional needs of the intended market segment [4]. This will ensure that the market does not perceive a big difference in the products developed in-house by the customer and outsourced via the vendor.

This pattern comprises understanding the emotional needs of the user i.e. to address the ‘big picture’ issues typically justifying the user features and the performance patterns.

Various emotional needs may arise out of the market research surveys. For example, one primary need of a HDD recorder may be to record/watch/delete TV programs. There could also be another need to keep memories alive by storing them on permanent storage like DVD/Blu-ray Disc.

Figure 8 depicts the user base pattern template.

Anatomy Details

Pattern manifestation v1.0Owning Domain Product Planning and StrategyRelated Patterns None

Anticipated frequency Upto 20% of customer requirement patternsPattern classification Strategy

Pattern Author Kousik Sankar

Situations where the pattern can be applied

Use this pattern in those situations where it is necessary to compare the intended user profiles of the customer and the vendor side-by-side.

Typically, this pattern should be used whenever the marketing personnel go scouting for a suitable customer.

Situations not to use the pattern None.

Market survey Ensure that the proper market survey is done and market results available in the appropriate regions where the product launch is intended.

Socio-economic targetsThere should be as far as possible, lots of similarities between the

customer target markets and that of the vendor's. Ideally they should be the same.

Dominant emotional needSpecify the dominant emotional need as to why the product will be used by each socio-economic class. This information has to be fed back to the

UF and UI patterns to ensure compliance.Ranking of importance to the

dominant emotional needs from each region

Rank the dominant emotional needs for each region and ensure that the need for each region is completely or partly met.

Abstraction level Remove the constraints from the user base list thereby abstracting the user base to such a level that it can be re-used across diverse customers.

3rd party softwareIf the customer has integrated a 3rd party software, then ensure that the

3rd party functionality is not disrupting the dominant emotional needs of all the target regions.

Output Result The output of this user base comparison should be a clear communication of the target users and the regional emotional needs to which they cater to.

General This section is optional and can be used to record the product planner's qualitative views which do not fit in any of the above sub-sections.

Extra Comments

User Base Pattern

Basic Details

Applicability

Content

Figure 8. User Base Pattern template.

D. User Interface pattern (UI): This pattern compares the types of user interface

styles and widgets/components proposed in the UIS (User Interface Specifications) of the vendor and the customer. Knowing the differences in the basic user interface paradigms between the vendor and the customer will help in adapting the vendor’s user paradigm with minimum modifications to that of the customer or vice-versa if there is a strong perceived advantage.

It is also better to decide (from a budget point of view) what levels of UI customization the vendor is willing to provide support for. We defined 5 levels of UI customization as depicted in Figure 9.

512512

Figure 9. Levels of UI Customization. This will help in underpinning the user interface

requirements very early in the project [5]. Figure 10 depicts the user interface pattern template.

Anatomy Details

Pattern manifestation v1.0Owning Domain User InterfaceRelated Patterns None

Anticipated frequency Upto 25% of customer requirement patternsPattern classification UI

Pattern Author Kousik Sankar

Situations where the pattern can be applied

Use this pattern in all UI discussions to ascertain the underlying UI paradigm. Typically, this pattern should be used whenever the total

number of screens (including dialogs) is more than 50.

Situations not to use the pattern Need not be used in situations where UI complexity is low or almost absent widgets.

Form of requirements Ensure that the UI requirements are in the same format as in xls or using same or similar requirements tools

Prototype based UI developmentAlways ensure that there is a prototype UI developed on the PC which

reflects the UI entities very closely. This can be used to converge quickly with geographically distant teams.

UI paradigms

The UI requirements captured should bring about the basic UI paradigms followed. For eg.system reconfirmation dialog boxes superimposed with system messages may give preference to one over the other depending on

the kind of UI philosophy followed.

UI editor

A UI editor processes the screen layout containing dialog boxes, multi-screen layouts, textboxes and other widgets and converts it into a form readable by the machine (like XML, C code etc). It helps to ensure that

similar (or the same) UI editors are use

UI customizationGet the list of customizable UI features in the vendor's software. Make it clear on the level of customization that is possible viz. UI assets change,

color change, screen layout change, 'look and feel' change.

Abstraction level Remove the constraints from the UI feature list thereby abstracting the UI requirement to such a level that it can be re-used across diverse customers.

3rd party softwareIf the customer uses any 3rd party software for certain UI asset

management etc, then it is better to ensure that the 3rd party UI is in-line with the vendor's UI paradigm.

Output Result The output of this UI comparison should be a technical report stating the level of customization possible within the vendor stack.

GeneralThis section is optional and can be used to record the UI engineer's views which do not fit in any of the above sub-sections. For eg if the customer

has plans to change the UI roadmap etc.

Extra Comments

User Interface Pattern

Basic Details

Applicability

Content

Figure 10. User Interface Pattern template.

III. RESULTS

We applied these patterns in our interactions with our suppliers to cater to the requirements of one of our high-end audio-video customer in Europe. The UF, PERF, UB and UI patterns were applied throughout the duration of the project. We got a customer satisfaction rating of 9.2/10. The major area of improvement was to incorporate a new pattern called as the TECH pattern to address technology issues like debugging frameworks, production line wastage reduction etc. IV. CONCLUSION

In this paper, we have proposed the customer

requirements pattern class, comprising of patterns that guide the specification and verification / validation of the resulting requirements specifications.

We are in the process of adapting the patterns to specific customers and also generating a pattern class that can cater to multiple customers. Following the detailed pattern classifications, we intend to have a generic customer requirement pattern class that will guide all future customer interactions.

ACKNOWLEDGEMENTS

The authors wish to thank Raman Venkat (General Manager, SlingMedia Inc.) and Dheeraj Baijal (Project Manager, Philips Innovation Campus, Bangalore) for their valuable thought-provoking insights.

REFERENCES [1] K. Wiegers, “Software Requirements”, Microsoft Press, March 2003, ISBN-13: 978-0735618794. [2] R. Pressman, “Software Engineering: A Practitioner's Approach,” McGraw Hill, January 2007, ISBN-13: 978-0073375977. [3] S. Withall, “Software Requirement Patterns,” Microsoft Press, June 2007, ISBN-13: 978-0735623989. [4] D. Callele, E. Neufeld, and K. Schneider, “Emotional Requirements in Video Games,” Proc. of 14th IEEE Requirements Engineering Conference 2006 (RE 2006), September 2006, pp. 299-302. [5] K. Sankar, and R. Venkat, “Total Requirements Control At Every Stage of Product Development,” Proc. of 15th IEEE Requirements Engineering Conference 2007 (RE 2007), October 2007, pp. 337-342. [6] A. van Lamsweerde, and E. Letier, “Handling Obstacles in Goal-Oriented Requirements Engineering,” IEEE Transactions on Software Engineering, Special Issue on Exception Handling, Vol 26, No 10, October 2000, pp. 978-1005. [7] A. Affleck, and A. Krishna, ‘‘Supporting quantitative reasoning of non-functional requirements: A process-oriented approach,’’ Proc. of International Conference on Systems and

513513

Software Process (ICSSP 2012), Zurich, Switzerland, June 2012, pp. 88-92. [8] A. Affleck, A. Krishna, and N. R. Achuthan, ‘‘Optimal Selection of Operationalizations for Non-Functional Requirements,’’ Proc. Conceptual Modelling 2013 (APCCM 2013), Adelaide, Australia, CRPIT 143, F. Ferrarotti, and G. Grossmann, Eds., ACS. pp. 69-78. [9] E. Yu, and J. Mylopoulos, “Understanding “Why” in Software Process Modelling, Analysis and Design,” Proc. of 16th International Conference on Software Engineering (ICSE 1994), May 16-21, 1994, Sorrento, Italy, pp. 159-168. [10] E. Yu, and J. Mylopoulos, “Why Goal-Oriented Requirements Engineering,” Proc. of the 4th International Workshop on Requirements Engineering: Foundations of Software Quality, Dubois, E., Opdahl, A. L., Pohl, K. (Eds.), June 8-9, 1998, Pisa, Italy, Presses Universitaires de Namur, 1998. pp. 15-22. [11] E. Yu, “Agent Orientation as a Modelling Paradigm,” Wirtschaftsinformatik 43Vol 2, April 2001, pp. 123-132. [12] L. Chung, B. A. Nixon, E. Yu and J. Mylopoulos, “Non-Functional Requirements in Software Engineering,” Kluwer

Academic Publishers, Boston Hardbound, ISBN 0-7923-8666-3 October 1999, 472 pp. [13] D. Gross, and E. Yu, “Evolving System Architecture to Meet Changing Business Goals: an Agent and Goal-Oriented Approach,” Proc. of the ICSE-2001 Workshop: From Software Requirements to Architectures (STRAW), Toronto, Canada. pp. 13-21. [14] V. Rahimian, and R. Ramsin, “Designing an agile methodology for mobile software development: A hybrid method engineering approach,” Proc. of the Research Challenges in Information Science (RCIS 2008), pp. 337-342. [15] J. Castro, M. Kolp, and J. Mylopoulos, “A Requirements-Driven Development Methodology,” Proc. of the International Conference on Advanced Information Systems Engineering (CaiSE 2001), Springer-Verlag LNCS 2068, Berlin Heidelberg 2001, pp. 108-123.

514514