Sunday, December 30, 2012

2012-12-30 Sunday - NFRs

Non-Functional Requirements (NFRs) are often poorly documented, and there is often ambiguity that exists in the definitions of terms used by different team members.

Often teams approach NFRs using a boil-the-ocean approach - in which case, all NFRs are treated equally (at best) - or ignored (at worst) by the developers en masse due to the sheer volume of NFRs specified.

Today I happened across a paper that was published in March 2012 as part of the
20th IEEE International

Requirements Engineering Conference

September 24th-28th, 2012. Chicago, Illinois, USA.

Report ESSI-TR-12-1
Departament d’Enginyeria de Serveis i Sistemes d’Informació
David Ameller
Claudia Ayala
Xavier Franch
Software Engineering for Information Systems Group
Universitat Politècnica de Catalunya (GESSI-UPC)
Barcelona, Spain

Jordi Cabot2
INRIA - École des Mines de Nantes
Nantes, France

A slide presentation is also available:

A few interesting quotes from the paper:

  • "Our interviews show that in 10 out of the 13 projects considered, the software architect was the main source of the NFRs."
  • "Architects did not share a common vocabulary for types of NFRs and showed some misunderstandings."
  • "The two most important types of technical NFRs for architects were performance and usability. On the other hand, architects considered non-technical NFRs to be as relevant as technical NFRs."
  • "Inability to interpret some particular term, e.g., “availability”, “accuracy”, and “sustainability”, requiring additional explanations from the interviewers"
  • "Use of a term with an incorrect definition. We found a serious confusion in the answer, e.g., “Maintainability is very important, because when something is working, we can’t make changes”

Other Resources Mentioned in the Paper
Volare Requirements Specification Template
ISO/IEC 9126 Software engineering - Product quality

Also see:

ISO/IEC 9126 in practice: what do we need to know?

ISO/IEC 25010:2011

Other Web Resource Links

Wednesday, December 12, 2012

2012-12-12 Wednesday - Windows MAX_PATH?

I love to create organization from chaos.

In my consulting practice, I have a very organized approach to creating a directory structure for each client engagement, and within an engagement - a very organized sub-directory layout so that I can quickly find things long after I've filed them away.

Recently, while trying to help re-organize the logical directory structure of a client's Sharepoint site for a project - I hit a puzzling error message:

[click to view]

Without intending to be too verbose, my relatively few nested directory names exceed a Sharepoint limitation. I had simply provided useful and meaningful directory names - and organized them in such a way as to facilitate quickly finding information.  However, some inherent implementation constraint in the design of Sharepoint results in an arbitrary maximum length constraint for an URL+filename (260 characters) and a further maximum length constraint on a file name (128 characters).

While one can understand a limit for a file name or a directory path in the physical file system - it just seems strange to have an arbitrary restriction on how deeply one can nest a logical 'directory' structure within a content management system.

In doing a quick Google search, I came across the following article that may be of interest to others, as it mentions a MAX_PATH with a default of [260]:

Maximum Path Length Limitation

In the Windows API (with some exceptions discussed in the following paragraphs), the maximum length for a path is MAX_PATH, which is defined as 260 characters. A local path is structured in the following order: drive letter, colon, backslash, name components separated by backslashes, and a terminating null character. For example, the maximum path on drive D is "D:\some 256-character path string" where "" represents the invisible terminating null character for the current system codepage. (The characters < > are used here for visual clarity and cannot be part of a valid path string.)

Seriously Microsoft? You designed an API that exposes a physical constraint of your file system design - and applied it to the web?

I suspect that if Sharepoint were designed with something like the JSR 170 approach (Content Repository API for Java) - then this type of limitation would not be an issue.

Apache Jackrabbit is an implementation of JSR 170

2012-12-16 Sunday Update:

Apparently there is another manifestation of this constraint in the Microsoft ASP.NET implementation:

HttpContext.Current.Server.MapPath fails for long file names

Back in 2006, some empirical findings were published on that are worth noting: you will note, 2,000 would appear to be a minimally supported length across the various browsers and servers that were tested.

Per Microsoft Support, IE supports a max. URL length of 2,083 I guess it is just the design and implementation of Sharepoint.


2013-03-24 Sunday Update

You will also run into this issue if you are still using xcopy  


Saturday, December 08, 2012

2012-12-08 Saturday - ISO 3166 Country Codes Utility Class

Last night I was looking for a small coding task that could be completed in an evening - that would allow me to add something of value to a personal utility library - and decided to work on a robust class to handle a variety of tasks related to ISO 3166 Country Codes.

[another one of my side projects is the implementation of a utility library of the United States Postal Service Pub 28 (Postal Addressing Standards) - of which this Country Code utility class will be of some re-use]

Two useful page references:

The utility class I'm working on provides a number of functional capabilities:
  • Stores the following Country Code Information:
    • Short English Name
    • Two Character Alpha Code (Alpha-2)
    • Three Character Alpha Code (Alpha-3)
    • Three Character Numeric Code (Numeric-3)
    • Top Level Domain (TLD)
  • Stores the Country Code data in a multidimensional array for most of the primary functional processing 
  • Stores a Key-Value entry in a HashMap to allow searching by the Short Name, as well as by the following codes: Alpha-2, Alpha-3, Numeric-3, and TLD
  • Utility method to generate an XML structure of the primary array information
  • Utility method to generate HTML select snippets codes for  either Apha-2, Alpha-3, or Numeric-3 value codes.  A parameter allows the developer to specify which Country Code to set as the 'selected' value.  The method determines which type of code was passed via inspection of the characteristics of the single parameter.
  • Utility method to generate the XSD Enumerations for the Alpha-2, Alpha-3, and Numeric-3 Country Codes.
  • Utility method to dump the contents of a Country Code array
  • Utility method to dump the contents of a HashMap - which is searchable by all possible Key-Value combinations
  • Utility method to query the length of the array
  • Utility method to query the size of the HashMap

I've posted  files for the generated HTML select samples on github:gist
I've posted a github:gist file for the XML snippet of the enumerations:


© 2001-2021 International Technology Ventures, Inc., All Rights Reserved.